Avi Kivity wrote: > Please split the signalfd() emulation into a separate (preparatory) > patch. Also, we need to detect signalfd() at run time as well as > compile time, since qemu may be compiled on a different machine than it > is run on. >
Ok. > We can keep the signals blocked, but run the signalfd emulation in a > separate thread (where it can dequeue signals using sigwait as an added > bonus). This will reduce the differences between the two modes at the > expense of increased signalfd() emulation complexity, which I think is a > good tradeoff. > signalfd() can't be emulated transparently with a separate thread because you won't be able to wait on signals destined for the specific thread (only signals sent to the process). We deliver signals directly to the IO thread (specifically, SIGUSR1) so this could get nasty. We could just not block SIGUSR1 and rely on the fact that it will break us out of select() but I that makes things a bit more subtle than I'd like. I personally prefer using pipe() within the same thread although I'm willing to also do the separate thread. Regards, Anthony LIguori > We can move signalfd emulation into a separate file in order to improve > readability. > > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
