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

    * Alan <alan@lxorguk.ukuu.org.uk> wrote:

    > > this "AIO atom" in the first place, WHICH WE KNOW IS INCORRECT,
    > > since current users use "aio_read()" that simply doesn't have
    > > that and doesn't build up any such data structures.
    >
    > Do current users do this because that is all they have, because it is
    > hard, or because the current option is all that makes sense ?
    >
    > The ability to avoid asynchronous completion waits and
    > complete/wake/despatch cycles is a good thing of itself. [...]

    yeah, that's another key thing. I do plan to provide a sys_upcall()
    syscall as well which calls a 5-parameter user-space function with a
    special stack. (it's like a lightweight signal/event handler, without
    any of the signal handler legacies and overhead - it's like a reverse
    system call - a "user call". Obviously pure userspace would never use
    sys_upcall(), unless as an act of sheer masochism.)

    [ that way say a full HTTP request could be done by an asynchronous
    context, because the HTTP parser could be done as a sys_upcall(). ]

    so if it's simpler/easier for a syslet to do a step in user-space - as
    long as it's an 'atom' of processing - it can be done.

    or if processing is so heavily in user-space that most of the logic
    lives there then just use plain pthreads. There's just no point in
    moving complex user-space code to the syslet side if it's easier/faster
    to do it in user-space. Syslets are there for asynchronous /kernel/
    execution, and is centered around how the kernel does stuff: system
    calls.

    besides sys_upcall() i also plan two other extensions:

    - a CLONE_ASYNC_WORKER for user-space to be able use its pthread as an
    optional worker thread in the async engine. A thread executing
    user-space code qualifies as a 'busy' thread - it has to call into
    sys_async_cachemiss_thread() to 'offer' itself as a ready thread that
    the 'head' could switch to anytime.

    - support for multiple heads sharing the async context pool. All the
    locking logic is there already (because cachemiss threads can already
    access the queue), it only needs a refcount in struct async_head
    (only accessed during fork/exit), and an update to the teardown logic
    (that too is a slowpath).

    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-14 23:39    [W:2.845 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site