Re: Refactoring our IO multiplexing layer

From: Date: Tue, 17 Jun 2014 11:33:58 +0000
Subject: Re: Refactoring our IO multiplexing layer
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-74941@lists.php.net to get a copy of this message
On 17 June 2014 12:05, Julien Pauli <jpauli@php.net> wrote: > CCing internals > > On Tue, Jun 17, 2014 at 1:07 PM, Martin Pelikan > <martin.pelikan@gmail.com> wrote: >>> Still, there exist the excellent libevent >>> http://libevent.org/ >> >> Speaking as only an observer to PHP development, I have been reinventing >> this particular wheel in my project (SSH client to thousands of machines >> to replace the painfully slow python's paramiko, as seen in my thesis at >> http://qviz.storkhole.cz/). >> >> My ~3 months of experience: >> >> The questions you want to ask are: >> - "what's wrong with libevent" >> - "how would you do it differently" >> - "why does PHP need it differently" >> >> I strongly suggest not creating yet another way of doing I/O multiplexing. >> nginx looks pretty neat and shows just how much work is needed to get things >> right on all platforms. PHP developers have better things to do than this. >> >> http://trac.nginx.org/nginx/browser/nginx/src#event/modules >> >> If someone would say to me "learn and then read libevent" right away, my >> backend would be finished now. Seriously. Go and have a look, it is >> likely to save a lot of your time. > > Yes, libevent seems to be the API we need. > Regading Nginx, I'm not sure we need file AIO, for PHP, network AIO > could be enough to implement. Still, our FPM IO multiplexing layer is > stable now. File AIO would still be nice to have though, it's common to pipe data between a network fd and a file fd - when the file system blocks, that can be a sizeable performance hit. I may get shot for suggesting this, but libuv provides all the things libevent provides, plus filesystem support (also, the built-in async DNS resolution is a nice bonus). > The problem of binding a lib is that you add one more dependency, you > have to check for licence compatibility, and check for the dependency > when building. Not talking about bugs in the lib impacting our > codebase. This is a tradeoff. While this is very valid, in this particular case I believe it would be worth it, due to the insane complexity of reinventing this particular wheel. I believe Daniel Lowrey and Joe Watkins were bouncing some ideas around on exactly this subject off-list a few weeks ago, I'm not sure whether they have anything tangible yet. Thanks, Chris

« previous php.internals (#74941) next »