On Mon, Oct 26, 2009 at 09:32:00PM -0700, Evan Klitzke wrote: > Is there any reason to set a socket as non-blocking using > fcntl/O_NONBLOCK before adding it to the libevent event loop? <snip> > * file descriptor gets data to read > * select() returns the socket as available for reading > * libevent invokes your callback > * another thread reads on the file descriptor > * you callback tries to read
On Linux (and perhaps other IP stacks), UDP checksums aren't validated until there's a read attempt. In such case, select()/poll()/etc will signal read readiness, the read triggers validation, the packet is discarded by the kernel, and your process is now blocked until a new, valid UDP packet arrives or the call is somehow interruped. It's not "cargo-cult" programming to always set non-blocking, it's prudent programming. I wouldn't even call it "belt-and-suspenders", either. select()/poll()/etc are only signaling a state that exists at that moment. Your hypothetical is another example of how the state of the socket could change in the interim. But there is no guarantee in the standards or elsewhere that limit the possible exceptions. Any attempt at enumerating the possibilities, even if perfect, can simply become invalid the next time some cool feature is added to the networking stack. *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
