Re: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support

[Davide Libenzi <davidel@xmailserver.org>]

On Wed, 14 Feb 2007, Jeremy Fitzhardinge wrote:

> Davide Libenzi wrote:
> >> Would this work?
> >>     
> >
> > Hopefully the API will simplify enough so that emulation will becomes 
> > easier.
> >   
> 
> The big question in my mind is how all this stuff interacts with
> signals.  Can a blocked syscall atom be interrupted by a signal?  If so,
> what thread does it get delivered to?  How does sigprocmask affect this
> (is it atomic with respect to blocking atoms)?

Signal context is another thing that we need to transfer to the 
return-to-userspace task, in case we switch. Async threads inherit that 
from the "main" task once they're created, but from there to the 
sys_async_exec syscall, userspace might have changed the signal context, 
and re-emerging with a different one is not an option ;)
We should setup service-threds signal context, so that we can cancel them, 
but the implementation should be hidden to userspace (that will use 
sys_async_cancel - or whatever name -  to do that).



- Davide


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