Re: [patch 04/13] syslets: core code

[Ingo Molnar <mingo@elte.hu>]

* 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