On 20 July 2013 10:50, Oleg Moskalenko <mom040...@gmail.com> 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 majord...@freehaven.net with unsubscribe libevent-users in the body.
