Hi all, Is there any reason to set a socket as non-blocking using fcntl/O_NONBLOCK before adding it to the libevent event loop? I've frequently seen this style done in programs that use select/epoll directly, and I've also seen it in various libevent examples floating around on the net. This always seemed strange to me, since libevent will already block until the file descriptor is readable/writable. I'm trying to figure out if there's any reason to actually to this, or if this is just a cargo cult type of thing.
One idea that I had is that this might be useful in a multi-threaded program, since the following could happen: * 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 In this example the other thread will have "stolen" your data, and your callback may then block when it tries to read. However, this example seems a bit unlikely to me; it would be a terrible program that was susceptible to this race, and I see the O_NONBLOCK usage in single-threaded programs. So are there any other legitimate uses for this pattern? Thanks. -- Evan Klitzke <[email protected]> :wq *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
