[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals.
Anthony Liguori writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals."): > Then you need a pipe per-signal and you can't accurately simulate > threadfd() (since you can't communicate siginfo). No, you don't need a pipe per signal. You only need multiple pipes if you have multiple different event loops which are each capable of handling only a subset of the signals, _and_ you're unwilling to use an atomic flag variable (eg, cpu_interrupt) or its equivalent. But we already have cpu_interrupt, and of course the aio completion system has its own recording of what's going on. So that does not apply to qemu. All that's needed is a reliable, race-free, way of avoiding spuriously blocking in a syscall when an event occurs between checking the state variables (aio_error, cpu interrupt check) and the call to select(). One fd is sufficient for that. Just to make that concrete, even if we extended my patch to use its mechanism for SIGINT et al I don't think a second pipe would be needed. > I don't see threads as a problem. Are you concerned about mini-OS? Minios certainly doesn't currently have any threads and it would probably be a severe pain to introduce them. That's just one example of a portability problem. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |