On Sat, Apr 16, 2016 at 2:17 PM, Yann Ylavic <ylavic....@gmail.com> wrote: > Hi Luca, > > On Sat, Apr 16, 2016 at 12:07 PM, Luca Toscano <toscano.l...@gmail.com> wrote: >> The sockets are non blocking and without any guard before the >> apr_pollset_poll (between processes I mean) there might be the risk of >> having two or more listener threads trying to accept the same new >> connection, ending up in only one proceeding and the rest getting EAGAIN. > > On modern systems, the thundering hurd is not an issue anymore (does > not happen). > There won't be multiple listeners (threads or processes) woken up at > the same time for the same incoming connection when > epoll_wait()/kevent()/... are used (see the corresponding man pages, > EAGAIN is not a possible error, while it is for eg. poll()). > So when accept() is called, we can be sure , so a fortiori for > epoll()+accept().
[Sorry, unexpected send...] So when accept() is called, we can be sure that a connection is available. > > Since, as you noticed, mpm_event is meant for modern systems, not > ACCEPT_MUTEX is implemented.
