Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74948
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hoa-project.net from 95.130.10.56 cause and error)
Message-ID: <53A05826.3070000@hoa-project.net>
Date: Tue, 17 Jun 2014 16:00:54 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Thunderbird/32.0a2
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAMUwpuQYOCnwCC7gKeNtmfwFKtbrGdS+TSd_wuZjDK+-xzXzCQ@mail.gmail.com>
In-Reply-To: <CAMUwpuQYOCnwCC7gKeNtmfwFKtbrGdS+TSd_wuZjDK+-xzXzCQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Refactoring our IO multiplexing layer
From: "\"Ivan Enderlin\"@Hoaivan.enderlin"@hoa-project.net

On 17/06/2014 11:04, Julien Pauli wrote:
> Hey :-)
Hello :-),


> I spent few hours analyzing PHP's IO multiplexing parts.
>
> IO multiplexing refers to calls to select() / poll() / epoll() or kqueue().
>
> Simple notice : everything is sparse everywhere, we don't have an
> IOmux layer designed.
>
> I plan to write an RFC on the subject.
> The goal is to centralize IO mux calls in a layer to be used
> everywhere. My analyze leads to those points :
>
> - FPM has something, but not designed to be shared
> - User streams use hardcoded select() , with an ugly emulation for poll()
> - We have nothing about epoll() or kqueue(), except in FPM
> - curl_multi_select() uses hardcoded select()
> - php_cli_server uses hardcoded select()
> - mysqlnd uses hardcoded select() for its poll() mecanisms
>
> Python already have a layer, at
> http://hg.python.org/cpython/file/abcf17bc5eae/Modules/selectmodule.c
>
> Apache's APR has a nice layer with adapters, at
> https://github.com/apache/apr/blob/trunk/poll/unix/pollset.c
>
> Still, there exist the excellent libevent http://libevent.org/
What about depending on libuv also https://github.com/joyent/libuv? It 
would offer nice major features.
(Another related link: https://github.com/chobie/php-uv)


>
> So basically, the first question will be do we need it ?
> I would say yes. As we are talking about PHP6 and modernising our API,
> it is time I think to implement IO mux correctly and don't use the old
> select() everywhere where there is a better implementation (epoll and
> kqueue are both faster, and they dont suffer from any FD_SETSIZE
> limit)
> Also, we didnt talk about things as websockets etc... yet, for PHP6 ,
> but it is sure that nowadays 2014, IO mux is a must-have.
>
> 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).
>
> And then, will people be interested by the RFC ?
I do.

Cheers.

-- 
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/