Refactoring our IO multiplexing layer

Hey :-) I spent few hours analyzing PHP's IO multiplexing parts. IO multiplexing refers to calls to select() / poll() / epoll() or kqueue(). Simple notice : everything is sparse everywhere, we don't have an IOmux layer designed. I plan to write an RFC on the subject. The goal is to centralize IO mux calls in a layer to be used everywhere. My analyze leads to those points : - FPM has something, but not designed to be shared - User streams use hardcoded select() , with an ugly emulation for poll() - We have nothing about epoll() or kqueue(), except in FPM - curl_multi_select() uses hardcoded select() - php_cli_server uses hardcoded select() - mysqlnd uses hardcoded select() for its poll() mecanisms Python already have a layer, at http://hg.python.org/cpython/file/abcf17bc5eae/Modules/selectmodule.c Apache's APR has a nice layer with adapters, at https://github.com/apache/apr/blob/trunk/poll/unix/pollset.c Still, there exist the excellent libevent http://libevent.org/ So basically, the first question will be do we need it ? I would say yes. As we are talking about PHP6 and modernising our API, it is time I think to implement IO mux correctly and don't use the old select() everywhere where there is a better implementation (epoll and kqueue are both faster, and they dont suffer from any FD_SETSIZE limit) Also, we didnt talk about things as websockets etc... yet, for PHP6 , but it is sure that nowadays 2014, IO mux is a must-have. Second question will be : do we use, and then link against libevent (or any other lib that could fit the need) , or do we develop our own layer, based on the FPM layer which is pretty nicely done (just not shareable elsewhere at the moment). And then, will people be interested by the RFC ? Thx, Julien