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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
