Re: Re: HTTP/2 and Websocket support in 7.x versions

From: Date: Thu, 02 Apr 2015 08:38:41 +0000
Subject: Re: Re: HTTP/2 and Websocket support in 7.x versions
References: 1 2 3 4 5 6 7 8  Groups: php.internals php.internals 
Request: Send a blank email to internals+get-85685@lists.php.net to get a copy of this message
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

« previous php.internals (#85685) next »