On Tue, Oct 27, 2009 at 11:46 AM, Eric M. Hopper <[email protected]> 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 [email protected] with unsubscribe libevent-users in the body.
