Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85711
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <551B15DF.5090105@hristov.com>
References: <CAH8MpnknSgzZEpsgqwfNMq5h8C5eM5RVREjvLwCA5YxLhMKc6Q@mail.gmail.com> <551AAB20.6060100@luni.fr> <CAH8MpnnxmD5+cd1jmndBTV7XA5TQTseXVE-p-D0tsqMh7=ZfDw@mail.gmail.com> <551AB705.5040001@hristov.com> <551ABCAF.4070008@gmail.com> <551B025C.6010702@hristov.com> <19D697AD-8FC9-4A49-A7B5-3577ED251830@gmail.com> <551B15DF.5090105@hristov.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Fri, 03 Apr 2015 17:24:20 +0100
To: Andrey Hristov <php@hristov.com>,internals@lists.php.net
Message-ID: <6603DFCA-8C2F-41CB-B309-F3D3A6BE73F2@gmail.com>
Subject: Re: [PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions
From: rowan.collins@gmail.com (Rowan Collins)

On 31 March 2015 22:47:11 GMT+01:00, Andrey Hristov <php@hristov.com> wrote:
>On  1.04.2015 00:31, Rowan Collins wrote:
>> On 31 March 2015 21:23:56 GMT+01:00, Andrey Hristov <php@hristov.com>
>wrote:
>>> So, if Zend can be optimized to quickly clean the execution
>>> environment,
>>> and easily switch between them, we can have a giant leap towards
>>> concurrent non-blockable PHP. The idea is simple - the Zend
>environment
>>>
>>> should be some structure, and TSRM needs implementation not using
>TLS,
>>> in this case. The MySQL Server used to bind a connection to a thread
>>> but
>>> since years these are decoupled and with the right plugin you can
>have
>>> 100 threads serving many times more connections because thread
>>> switching
>>> is an expensive task. This ain't rocket science.
>>
>> You make it sound so simple, but the fact that an environment is set
>up and torn down for each request is fundamental to the whole language,
>not just a detail of the engine.
>>
>> If all you're doing is making that setup and teardown quicker, I
>don't see how you're getting any closer to asynchronous code. FPM could
>do all sorts of magic with its memory management, but it wouldn't help
>someone write a WebSocket server.
>
>being able to serve more than 1 request in a thread by not using TLS 
>allows you to lower the number of threads used, significantly. On top
>of 
>that by adding coroutines which run on a thread pool with fast setup
>and 
>teardown give you the notion of parallel execution and because data is 
>exchanged with the coroutines only in serialized way, not by sharing
>it, 
>a bunch of problems related to concurrency won't happen. Add promises
>to 
>this soup together with non-blocking APIs (this won't happen overnight)
>
>and everything fits.
>
>> Maybe I'm missing something, but I can't picture how you'd have a
>meaningfully event-based SAPI that looked just like a single-request
>one to the user.
>
>I don't think that the SAPI needs to change. The SAPI doesn't mandate 
>processes, threads or whatever else primitives. It's a way to 
>(de)initialize module/request.

The SAPI needs to change to have coroutines as something that can be allocated on an arbitrary thread pool. PHP contains a lot of things which imply global state (I came up with a list in a previous thread) and those are what I mean by setup and teardown. However fast you make them, they have to happen exactly once per userland script execution.

In an event-based environment, you either have to not use any such global state (which makes for a very different language), or it has to be shared between all your lightweight workers, in which case those workers can see each other at the userland level.

You can implement this in userland right now, using the CLI SAPI as the container of global state, and a co-operative multi-tasking scheduler built with clever use of "yield". A scalable and efficient version of that would be a new SAPI, and would have to make some tough choices about how existing features behaved, or if they were allowed at all.

Regards,
-- 
Rowan Collins
[IMSoP]