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()) -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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
