On 01/23/2013 07:31 PM, John Reiser wrote: > On 01/23/2013 10:35 AM, Dan Williams wrote: >> On Wed, 2013-01-23 at 09:48 -0800, John Reiser wrote: > >>> The signal handler can write a packet into a pipe from the process to itself, >>> and that can be hooked up to an event loop API. > >> Clearly. But then you have to deal with signal handling and all the >> things you're not able to do from a signal handler like allocate memory, >> figure out any locking that may be required, and deal with signal >> handler re-entrancy. (...) This is known as the self-pipe trick. Doing a web search for that term will find lots of advice on how to use it properly. > This is exactly what the signal+pipe scheme facilitates; > you get to write a couple dozen lines of straight-line code. > The main loop gets notified that the pipe has a packet, > then calls the NM callback. All the NM callback has to do is > read the fixed-length packet from the pipe, unwrap the answer, > and feed it to the client's callback. Right. The issue with signal based interfaces is that they're fundamentally bad for multi-threading and libraries -- signal dispositions/handlers are global per process, not per thread. If two different libraries loaded into a process want to use/reserve the same signal (which also steals a signal from the main program), you're in trouble. See this 4 blog series about exactly this issue around wait/SIGCHLD in Qt/glib for example: http://www.macieira.org/blog/2012/07/forkfd-part-4-proposed-solutions/ -- Pedro Alves -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
