Newsgroups: php.internals,php.internals
Path: news.php.net
Xref: news.php.net php.internals:85685 php.internals:85686
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,Andrey Hristov <php@hristov.com>, internals@lists.php.net
Message-ID: <551D0011.2040406@luni.fr>
Date: Thu, 02 Apr 2015 10:38:41 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
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>
In-Reply-To: <551B15DF.5090105@hristov.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions
From: gregory@luni.fr (=?UTF-8?B?R3LDqWdvcnkgUGxhbmNoYXQ=?=)

Le 31/03/2015 23:47, Andrey Hristov a écrit :
> 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.
>
>> Regards,
>>
>
> Best,
> Andrey
Hi Andrey,

So, if I understand your point, there could be a way to implement a SAPI 
without TSRM (or a limited set)?

Grégory Planchat