Re: [Libevent-users] missing EINTR handling?

[Pierre Phaneuf <pphaneuf@xxxxxxxxxx>]

On Tue, Oct 27, 2009 at 11:46 AM, Eric M. Hopper <hopper@xxxxxxxxxxxxxxx> wrote:

>> I also wonder why EINTR isn't handled at the evbuffer level, say,
>> since there is pretty much nothing else to do than retry it
>> immediately, isn't it? As opposed to EAGAIN, say, which requires
>> retrying it at a later time, when another event comes in...
>
> Actually, EINTR can be useful for moving signal handling back into the
> normal flow of a program.  EINTR tells you that one happened so you can
> go back to the main event loop and dispatch the signal handler if need
> be.

I don't think this is the case there, since when EINTR gets returned,
the connection gets marked as being failed, which I can only assume as
having dire consequences for the rest of the HTTP exchange!

This approach would make sense when using blocking I/O, I think, but
with non-blocking I/O, it would only come into play if you needed to
give your signal handling a really high priority (the write() call
that you'd retry is going to be fast, since it'll return EAGAIN if it
was going to be slow, we'll be going back to the main event loop soon
anyway), and since libevent uses a "write a byte to a pipe" flavour of
signal handling (I think?), I don't think there's allowance for that
kind of super-low latency signal handling.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.