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    [from the cache]
©2003-2011 Jasper Spaans