Messages in this thread |  | | Date | Wed, 14 Feb 2007 18:07:30 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support |
| |
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/
|  |