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


* Davide Libenzi <davidel@xxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages