> > > I think it still suffers from the same race condition so today it > > > wouldn't work. You could fix the bottom half scheduling though so that > > > you could safely schedule a bottom half from a signal handler (using > > > roughly the same trick). > > > > Fwiw, it's perfectly sensible to have a single pipe which is shared by > > all signal handlers, just used to say "check for work flags set". > > And if you need the main loop to be able to distinguish signals coming > out of the pipe, then just write the signum into the pipe as a byte, > instead of a single dummy byte. Or even write the whole 'siginfo_t' > struct passed to the signal handler, and read it out in sizeof(siginfo_t) > sized chunks for processing. I don't think this will works. If the pipe buffer gets full the write will either block or you'll loose signals. When using the pipe as a simple semaphore all you care about is the presence or absence of data. It doesn't matter if subsequent writes loose data (e.g. by not retrying a nonblocking write) as long as a write to an empty pipe succeeds. Paul -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
