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