Hi Rowan
> Could you share some more thoughts on what you are thinking of here? I'm
> guessing you're thinking along the lines of an "event-based" system,
> where each request is a function call, rather than a whole script
> invocation?
Yes that is what I was thinking, for example there is a userspace implementation
'Swoole' that works in the following way, ReactPHP is similar although I won't
include that example as well.
-------------------------
<?php
$http = new Swoole\HTTP\Server("127.0.0.1", 9501);
$http->on("start", function ($server) {
echo "Swoole http server is started at http://127.0.0.1:9501\n";;
});
$http->on("request", function ($request, $response) {
$response->header("Content-Type", "text/plain");
$response->end("Hello World\n");
});
$http->start();
-------------------------
> PHP is sometimes described as having a "shared nothing" architecture -
> everything is wiped out at the end of each requests - so perhaps one way
> to look at this is to propose a "shared something" version.
>
> The first question is _what_ we want to share. We already have sharing
> of compiled code, with OpCache bundled since 5.5, and the pre-loading
> feature in 7.4 could make autoloading redundant for many applications.
> What we can't share natively is any data structures, resources like
> database connections, or other global state like set_error_handler.
The concept of a shared nothing architecture is a great basis for designing
scaleable systems, and it does reduce/eliminate some types of bugs. However it
may be better to approach this at a conceptual level instead of enforcing it
with the design of the language.
In my mind right now, everything should be shareable within a single process,
as one could do in the Swoole example above, nothing stopping you defining a
global in that script that could cache data in-process.
NodeJS, Python (wsgi) and others work fine using this model and allow sharing
of data within the same process. Trying to limit it to only some types of things
would be more complex as each type of thing would end up having a different
programmatic interface.
Changing the execution model would also allow PHP to natively handle
web-sockets natively without 3rd party implementations, which are all based
around long running processes. I got the following from the Swoole docs:
-------------------------
<?php
$server = new Swoole\Websocket\Server("127.0.0.1", 9502);
$server->on('open', function($server, $req) {
echo "connection open: {$req->fd}\n";
});
$server->on('message', function($server, $frame) {
echo "received message: {$frame->data}\n";
$server->push($frame->fd, json_encode(["hello", "world"]));
});
$server->on('close', function($server, $fd) {
echo "connection close: {$fd}\n";
});
$server->start();
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
