Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74952
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.173 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAFMT4NqMWsQ04XDB3EGEOJQMO6kVR+84ft8tucLH5C+TaReLTg@mail.gmail.com>
References: <CAMUwpuQYOCnwCC7gKeNtmfwFKtbrGdS+TSd_wuZjDK+-xzXzCQ@mail.gmail.com>
 <CAFMT4NqMWsQ04XDB3EGEOJQMO6kVR+84ft8tucLH5C+TaReLTg@mail.gmail.com>
Date: Tue, 17 Jun 2014 16:57:46 +0200
Message-ID: <CAMUwpuR=UwvcyVHTV8nS7Fj=iTOAa+xBrkxnUjOJnx+VbMnJ+g@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: 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 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