Messages in this thread | | | Date | Tue, 6 Feb 2007 12:25:00 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [PATCH 2 of 4] Introduce i386 fibril scheduling |
| |
On Mon, 5 Feb 2007, Kent Overstreet wrote:
> > > HOWEVER, they get returned differently. The cookie gets returned > > > immediately, the system call result gets returned in-memory only after the > > > async thing has actually completed. > > > > > > I would actually argue that it's not the kernel that should generate any > > > cookie, but that user-space should *pass*in* the cookie it wants to, and > > > the kernel should consider it a pointer to a 64-bit entity which is the > > > return code. > > > > Yes. Let's have the userspace to "mark" the async operation. IMO the > > cookie should be something transparent to the kernel. > > Like you said though, that'd require compat-code (unless we fix the size). > > You don't need an explicit cookie if you're passing in a pointer to > the return code, it doesn't really save you anything to do so. Say > you've got a bunch of user threads (with or without stacks, it doesn't > matter). > > struct asys_ret { > int ret; > struct thread *p; > }; > > struct asys_ret r; > r.p = me; > > async_read(fd, buf, nbytes, &r);
Hmm, are you working for Symbian? Because that's exactly how they track pending async operations (address of a status variable - wrapped in a class of course, being them) ;) That's another way of doing it, IMO no better no worse than letting explicit cookie selection from userspace. You still have to have the compat code though, either ways.
- Davide
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |