Le 31/03/2015 16:40, Daniel Lowrey a écrit :
The issue here is this: the web SAPI is historically the most stable thing
about PHP. Supporting things like message push and multiplexing would
require a fundamental change in what the web SAPI is. You would have to
junk the entire model and create something completely new. It wouldn't be
PHP anymore because you couldn't use the thread/process per-request model;
users could no longer rely on the ease and simplicity of every function
call being a simple synchronous operation.
This kind of major paradigm shift is something that couldn't remotely be
considered for PHP7. Even if it were possible you have to consider the web
SAPI's target demographic. This demographic knows nothing about
non-blocking IO and multitasking.
I'm not saying that we should drop the current web SAPIs to the ground,
I'm just advancing the idea of enhancing it or find some other way - in
parallel of existing SAPIs - to bring these functionalities, maybe a
specific SAPI.
CLI SAPI is already using an unique RINIT/RSHUTDOWN cycle, programs such
as ReactPHP or the one I built with php-uv -and probably the one you
mentioned building yourself- suffers from brutal crashes on fatal errors
and does not take benefit from the request isolation. These issues will
be indirectly and partially addessed with the ZE now sending exceptions
instead of E_ERROR.
Now, about asynchronous operations, PHP developers are also often
Javascript developers, may it be front end or back end on Node. Lots of
them are used to asynchronous calls, others will simply learn to be used
to it or continue to use the current synchronous functionalities and
SAPIs, I see this as an opt-in.
Lots of PHP developers don't know what is a process or a thread and
doesn't feel the need to dig the subject and I'm perfectly ok with that,
each project finds his own needs and solutions. That said, then why
should concerned developers suffer from missing functionalities?
I used to be a proponent of integrating things like this directly into the
core of PHP. However I no longer consider this to be a good idea. Why?
Because all of the functionality needed to implement these things yourself
is available in extensions *right now.* I've personally worked on a
closed-source userland non-blocking HTTP+websocket server over the last
couple of years that clears 80,000 requests per second with 10,000
simultaneous clients running PHP7 on a single box with an i2600K cpu.
Is this server running with php-uv?
The issue here is that there is no simple and uniform way to implement
it. Agree with me or not, it is clearly reserved to a small part of
seasoned PHP developers, used to concurrent programming, extension
writing/compilation and asynchronous development.
It is a border-line way of developing with PHP, not portable at all as
long as php-uv isn't available anywhere but on your own dedicated server
(if your SysOP even accepts to install a considered self-maintained and
possibly vulnerable extension).
Instead of massively changing the fundamental nature of the PHP web SAPI I
believe we should focus on improving PHP as a language and not a web
framework. By doing so we make it increasingly possible to implement things
like this directly in userland with good performance. This can be
accomplished right now by simply focusing on extension development (like
php-uv which you mentioned and I've contributed to myself).
I'm just bringing some ideas here, as long as I'm not a php-src
developer. I know some notions but I don't have the distance required to
find -by myself- the best solutions.
Yes php-uv is a great tool, but still incomplete (and IMO missing an OOP
API).
Would I personally prefer to re-implement everything in PHP on top of libuv
and bake non-blocking and threaded concurrency directly into the language
with async functions and promises? Absolutely. But you're talking about a
massive amount of work here. In standard internet parlance ... ain't no one
got time for that.
I can't tell if the existing stream API can integrate libuv I/O
handling, especially async ones. I figured out that it was nearly
impossible to integrate php-uv in an userland streamWrapper.
Now, that said and to come back to the main subject, HTTP/2 is coming
*now* in production on large scale websites and will be present in a
large amount of web traffic in the next couple of years. PHP can't
afford to miss the boat or to force each developer reimplement his own
protocol layer.
Possible solutions would be :
1. About multiplexing :
1.a. integrate php-uv in the core in its current form and let
developers implement their own protocol layer
1.b. transform some project like ReactPHP into an extension (using
Zephir and/or native C)
1.c. create a new SAPI or extend an existing one, which woud offer
the possibility of manipulating the resource multiplexing queue. PHP
would still be in the Apache2/CGI stack, but would notify the server to
send a resource list
2. About push: same as 1.a. and 1.b.
Grégory
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
