Avi Kivity wrote: > Anthony Liguori wrote: >>> 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. >> > > We can completely kill off SIGUSR1 and replace it with its own pipe. > There's hardly any point in asking the kernel to signal a task, then > having the kernel convert this to a fd write. > > (Or maybe use eventfd())
That's a really good idea. I'll update the patch. Regards, Anthony Liguori ------------------------------------------------------------------------- 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
