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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/