* Davide Libenzi <davidel@xmailserver.org> wrote:
> > No, it absolutely is a matter of speed. The reason to have those
> > two implemented that way is so that they can be implemented as
> > vsyscalls completely in userspace. This means that on most modern
> > platforms you can implement the "make a threadlet when I block"
> > semantic without even touching kernel-mode. The way it's set up all
> > you'd have to do is save some parameters, set up a new callstack,
> > and poke a "1" into a memory address in the TLS. To stop, you
> > effectively just poke a "0" into the spot in the TLS and either
> > return or terminate the thread.
>
> Right. I don't why but I got the implression Ingo's threadlet_exec
> example was just sketch code to be moved in a syscall. That's why I
> was talking about a sys_threadlet_exec. But yeah, it makes a lot of
> sense to turn threadlet_exec in a glibc thing, and play everything in
> userspace at that point.
yeah, not having to do any extra entry into the kernel at all (in the
cached case), and to make them in essence equivalent to a function call
is my plan/hope for threadlets :-)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
