Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Pedro Alves]

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