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:3.382 / U:0.252 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site