Question

I’m writing tcp server using libev.
I’m creating socket and forking after listen(), then starting a libev read watcher on listening socket and receiving client connections in watcher callback.
May it be situation, when both: child and parent (or two childs if there is more than one) received event that listening socket became readable and both will try accept() client connection, in this case one of processes will block ?
I written test program and it seems that only one process receives read-ready event, but maybe i’m wrong? Where i can read about system behavior in this case? How kernel does load balancing between processes and decides who will receive event? Is it backend (select, epoll etc…) and/or OS specific?

Answer 1

Is is very much possible that both processes will receive a readiness indication from the socket and that both will as a result call accept(). That’s one of the reasons why you should always use nonblocking file descriptors with event-based APIs like socket(), poll(), epoll(), or kqueue() (or libev, which provides an abstraction for one or more of these). If you use nonblocking sockets then one child will get a successful result from accept() and all the others will get an EAGAIN, ignore it, and go back to sleep with no harm done.