Re: Refactoring our IO multiplexing layer

On Tue, Jun 17, 2014 at 4:28 PM, Levi Morrison <levim@php.net> wrote: > On Tue, Jun 17, 2014 at 4:04 AM, Julien Pauli <jpauli@php.net> wrote: >> So basically, the first question will be do we need it ? > > I would like it, yes. Having a IO abstraction layer internally would > be really nice. I'm not up-to-date on all the PHP extensions that > would facilitate this behavior, but perhaps some improved version of > the libuv extensions would be great. I am not sure on the health of > those extensions (I believe there are at least two of them) but it's > worth investigating at least. Potentially it could save us some work > as well as well as give us a bit more confidence. > >> 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). > > I also favor libuv over libevent; to be completely fair I have only > used both of them a little bit but I liked libuv a bit more. > > We definitely shouldn't roll our own. If we had corporate funding then > rolling our own would have the advantage of not having to wait for > upstream merges for bug fixes, but I don't think we have the manpower > or interest to build and maintain our own. I'm glad there seem to be interest in the subject, I had a good feeling while writing the mail. Like Daniel said => IOs is the 2014 bottleneck , and as you can see from my analyze of the current situation, we have all but a clean IO API. I'm gonna start writing the draft RFC this week so that the ideas are tied into a single place. I'll be able to invest some time developping such a layer. Feel free to ping on IRC or intern@ls if one wants to join the effort. The idea will then be to create a branch for some experiment. I'm not confident about threads. Threads is another topic (which shares some comon technical ideas with IOs, such as locking) , and I think we should treat threads in an other RFC Julien Pauli