Re: Refactoring our IO multiplexing layer
| From: | Chris Wright | 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