Re: [Libevent-users] Re: libevent2 stuck in Linux, CPU 100%

[Adrian Chadd <adrian@xxxxxxxxxxxxxxx>]

On 20 July 2013 10:50, Oleg Moskalenko <mom040267@xxxxxxxxx> wrote:
> Nick, that was not the very bottom of it :)
>
> I got email from Alexander Drozdov with a note that this behavior only
> happens when IP_RECVERR is set on the socket. Well, that's true: without
> this flag, there is not such effect. Why I am setting this flag is another
> story. But, supposedly, when a person is setting this flag, he/she must
> understand what the person is doing.

That's good to know.

If only there were a library useful for abstracting out the different
way that socket IO is done.. :-)

> Still, it would be probably nice-to-mention in the documentation, for Linux
> only. Something like that: "if a Linux socket is having an error stored in
> the message queue, then it will result in a "read" callback with empty input
> data. This callback will be poppoing up indefinitely until the error queue
> got cleaned in the application code, by using recvmsg with MSG_ERRQUEUE
> flag."
>
> May be future UDP-based bufferevents can somehow provide a higher interface
> to that.
>
> By the way, I have, to some extend, a similar situation with TCP sockets.
> When I have a listening socket, and the number of socket exceeds the system
> limit, then I am getting messages from the listening libevent callback like:
>
> [warn] Error from accept() call: Too many open files
>
> Basically, the system just has to wait till the socket number decreases.
> Reporting million errors to the stderr at this moment, from my point of
> view, rather pointless. Understandably, accept() has problems in the too
> many open files condition, but I am not sure that it has to be reported to
> stderr so many times.

Same deal here. It'd be nice to represent this in an OS-agnostic way
so you don't end up with everyone just using EV_READ on accept
sockets, and then having to special case everything. :(



-adrian
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.