Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74942
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.171 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAGAGxbZR+mcGmWK3XyTVkmCacyebQga+TjVbwo+NbESopvzgHw@mail.gmail.com>
References: <CAMUwpuQYOCnwCC7gKeNtmfwFKtbrGdS+TSd_wuZjDK+-xzXzCQ@mail.gmail.com>
 <20140617110758.GD24253@methuselah> <CAMUwpuTJ8maEBSXH5sKoy_2YP7HwMj5jr6H+Cqnx0yp4G7TE7Q@mail.gmail.com>
 <CAGAGxbZR+mcGmWK3XyTVkmCacyebQga+TjVbwo+NbESopvzgHw@mail.gmail.com>
Date: Tue, 17 Jun 2014 13:49:05 +0200
Message-ID: <CAMUwpuQ+AO7vf4wsd5KOghdYo-Vfn_OJ8Wc9RM+x12CAHbujvQ@mail.gmail.com>
To: Chris Wright <daverandom@php.net>
Cc: Martin Pelikan <martin.pelikan@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Refactoring our IO multiplexing layer
From: jpauli@php.net (Julien Pauli)

On Tue, Jun 17, 2014 at 1:33 PM, Chris Wright <daverandom@php.net> wrote:
> 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.

Libuv seems nice as well, yes.
Not sure about its licencing compatibility with us though.

>
> 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).

Why not use this part as well in our DNS resolutions, could be nice.

>
>> 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.

+1 !

>
> 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.

So, waiting for them to jump into the topic :-)


Julien