[lkml]   [2007]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2 of 4] Introduce i386 fibril scheduling

On Mon, 5 Feb 2007, Kent Overstreet wrote:
> 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);

That's horrible. It means that "r" cannot have automatic linkage (since
the stack will be *gone* by the time we need to fill in "ret"), so now you
need to track *two* pointers: "me" and "&r".

Wouldn't it be much better to just track one (both in user space and in
kernel space).

In kernel space, the "one pointer" would be the fibril pointer (which
needs to have all the information necessary for completing the operation
anyway), and in user space, it would be better to have just the cookie be
a pointer to the place where you expect the return value (since you need
both anyway).

I think the point here (for *both* the kernel and user space) would be to
try to keep the interfaces really easy to use. For the kernel, it means
that we don't ever pass anything new around: the "fibril" pointer is
basically defined by the current execution thread.

And for user space, it means that we pass the _one_ thing around that we
need for both identifying the async operation to the kernel (the "cookie")
for wait or cancel, and the place where we expect the return value to be
found (which in turn can _easily_ represent a whole "struct aiocb *",
since the return value obviously has to be embedded in there anyway).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-02-06 21:49    [W:0.180 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site