Hi Yann! 2016-04-16 14:20 GMT+02:00 Yann Ylavic <ylavic....@gmail.com>:
> 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. > Thanks a lot for the answer, it makes more sense now but I still have some doubts. I'd have some questions for you :) My understanding is that each process/thread block initializes an event_pollset containing initially all the listening sockets (from Listen) and then later on all the ones related to keep alive / lingering close / etc.. sockets re-assigned to the listener by workers. Each process/threads block handles separate sockets except the listening ones that are "shared" (my understanding). Before sending the email I took a look to http://man7.org/linux/man-pages/man7/epoll.7.html and Q2/A2 (Q&A) states that the same socket "monitored" by different pollsets (or epoll instances, depending on the nomenclature) will get reported in each of them once an event is ready. EPOLLONESHOT seemed the only flag for epoll_ctl to use to avoid multiple threads/processes waking up at the same time, but I didn't find any trace of it in apr/httpd. So I am still super confused about how multiple listener threads (belonging to different processes and pollsets) won't be woken up at the same time by epoll_wait when a new connection lands to httpd. The explanation that I gave to myself was that with non blocking sockets and very few listeners the overhead of getting all of them to (try to) accept the same connection is not that heavy and could be acceptable performance wise (a simple EAGAIN returned by accept is not a big deal). I know that my understanding about epoll/httpd is really wrong but still not super convinced about where. If you still have patience (and time), would you mind to point me to a snippet of code that could solve my doubts? I am asking tons of questions because I'd like to write the most precise info in the docs without risking to confuse more readers like me (for example in http://httpd.apache.org/docs/current/misc/perf-tuning.html#runtime). Thanks a lot! Regards, Luca