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. In cases like this one, it is easy to avoid all those problems. The packet is fixed length [and in this case probably includes both the actual request and the result], declared locally in the handler, allocated on the stack. A plain write() of the packet requires no locking (small writes on a pipe are atomic), and no concerns about re-entrancy (order cannot matter). The most that could matter is filling the pipe, but on linux you get at least 64kB before that happens, which should be enough for hundreds of packets that have not yet been processed by the main loop. If it matters, then use one atomic counter keep track of how many packets the pipe contains; you get to decide what to do if it overflows (probably: log the occurrence, then drop the packet.) > It's much easier for consumers of your library to > give them an API that can be easily integrated into their event loop > using select(). <<snip>> > [1] eg, client asks for a name lookup and hands your library a callback > function, your library constructs and sends the DNS request, then gives > control back to the caller and lets them select() on the UDP socket, and > when data is available they call back into your library so you can > handle the response, and when you have one you call the client's > callback 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. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
