On Thu, 1 Mar 2007, Ingo Molnar wrote:
>
> wrt. one-shot syscalls, the user-space stack footprint would still
> probably be there, because even async contexts that only do single-shot
> processing need to drop out of kernel mode to handle signals.
Why?
The easiest thing to do with signals is to just not pick them up. If the
signal was to that *particular* threadlet (ie a "cancel"), then we just
want to kill the threadlet. And if the signal was to the thread group,
there is no reason why the threadlet should pick it up.
In neither case is there *any* reason to handle the signal in the
threadlet, afaik.
And having to have a stack allocation for each threadlet certainly means
that you complicate things a lot. Suddenly you have allocations that can't
just go away. Again, I'm pointing to the problems I already pointed out
with the allocations of the atom structures - quite often you do *not*
want to keep track of anything specific for completion time, and that
means that you MUST NOT have to de-allocate anythign either.
Again, think aio_read(). With the *exact* current binary interface.
PLEASE. If you cannot emulate that with threadlets, then threadlets are
*pointless*. On eof the major reasons for the whole exercise was to get
rid of the special code in fs/aio.c.
So I repeat: if you cannot do that, and remain binary compatible, don't
even bother.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
