Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74941
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.172 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <CAMUwpuTJ8maEBSXH5sKoy_2YP7HwMj5jr6H+Cqnx0yp4G7TE7Q@mail.gmail.com>
References: <CAMUwpuQYOCnwCC7gKeNtmfwFKtbrGdS+TSd_wuZjDK+-xzXzCQ@mail.gmail.com>
	<20140617110758.GD24253@methuselah>
	<CAMUwpuTJ8maEBSXH5sKoy_2YP7HwMj5jr6H+Cqnx0yp4G7TE7Q@mail.gmail.com>
Date: Tue, 17 Jun 2014 12:33:58 +0100
Message-ID: <CAGAGxbZR+mcGmWK3XyTVkmCacyebQga+TjVbwo+NbESopvzgHw@mail.gmail.com>
To: Julien Pauli <jpauli@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: daverandom@php.net (Chris Wright)

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