Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85605
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hristov.com from 91.196.125.214 cause and error)
Message-ID: <551B025C.6010702@hristov.com>
Date: Tue, 31 Mar 2015 23:23:56 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
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>
In-Reply-To: <551ABCAF.4070008@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions
From: php@hristov.com (Andrey Hristov)

On 31.03.2015 18:26, Rowan Collins wrote:
> Andrey Hristov wrote on 31/03/2015 16:02:
>> Currently in MT environment the task of data separation is pushed to
>> the TSRM by using TLS. Now, if TSRM is reimplemented in a fashion that
>> the data is not stored by using TLS but other mechanism and
>> cooperative multitasking is not something that can't be done. The
>> truth is that userland is isolated from the process data space so for
>> it it won't make a difference. It's just that using threads for
>> separation is the easiest thing (after process per script).
>> The good thing is that TSRM is an abstraction for its clients.
>
> Isn't the point that to get a real advantage from these technologies,
> the *userland* needs to be aware of threads / events? That's what
> requires a fundamental rethink of the language.

No, actually it doesn't need threads. There is no need to introduce 
threads. Threads are for coarsely grained tasks. It is overkill to start 
and finish threads in this environment. It is not overkill to have pool 
of threads that can execute simple tasks.
PHP doesn't have this problem - the need for threads. PHP's problem are 
all the blocking APIs, including the ones I have worked on and created 
myself. PHP needs non-blockable APIs + a notion of coroutines + 
promises. How the coroutines are scheduled is not important (whether in 
the same thread, on thread pool, even in another process). Directly 
sharing data should not be possible, only serialized input/output.

> TSRM/TLS allows you to drop from one-process-per-request to
> one-thread-per-request, but it doesn't save you the expense of
> repeatedly building up and tearing down an execution environment.

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.

> Regards,

Best,
Andrey