lkml.org 
[lkml]   [2007]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 04/13] syslets: core code

* 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 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/

\
 
 \ /
  Last update: 2007-02-25 09:09    [W:0.183 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site