Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108257
MIME-Version: 1.0
References: <CAMuFt-6V24w6o8-hoPeRETCtfW25OtQ3KwdYprpYoQqpNQ2OsQ@mail.gmail.com>
 <3ca6d665-1a4f-8f7a-c82a-2e899f2e8df1@gmail.com> <CAMuFt-6Urf=7rXgR08_OsNSkBQeKVR84DisCc+2kyQXcJPuq0g@mail.gmail.com>
 <44ba543d-b6eb-888b-9ed5-0f1e9d3b53b9@gmail.com> <8E382251-AE41-4BD9-A5F8-135D11B9E10D@newclarity.net>
 <c2848f32-b06f-6711-8cbd-7fcba263ce29@gmail.com> <98A11C8F-6B51-4774-A2F6-6B6C7311180B@newclarity.net>
In-Reply-To: <98A11C8F-6B51-4774-A2F6-6B6C7311180B@newclarity.net>
Date: Mon, 27 Jan 2020 07:19:49 +0000
Message-ID: <CAMuFt-4aqMp-w1r=+wQYVh5bVKJYsiB+DhPO268Evi2zUjnRBg@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: Rowan Tommins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000718cb3059d19ef2f"
Subject: Re: [PHP-DEV] Add viable long running execution model to php 8
From: robehickman@gmail.com (Robert Hickman)

--000000000000718cb3059d19ef2f
Content-Type: text/plain; charset="UTF-8"

> > I'm not sure that would work well for Web Sockets, because it still
> relies on the traditional request-response cycle, but I've never really
> used them, so don't know what kind of architectural patterns make sense for
> them.
>
> Considering the Swoole PHP extension (https://www.swoole.co.uk) the
> long-running process would take the place of its functionality and new apis
> to communicate with a long running process could allow communication that
> resulted in regular requests being able to send messages via the web socket
> server, and read queued messages from the web socket server.
>
> You won't be able to process notifications to clients via
> request-response, but where that is needed it would be done by the
> long-running process. So the request-response might "register" a
> notification listener to the long-running process, for example.
>

A web socket is just a way of re-using the tcp connection from a http
request and holding it open for bidirectional communication. Due to this
you can make assumptions about performance charicteristics from other long
running socket server approaches.

From what i understand, the main problem with using fork or a thread pool
for handling sockets syncroniously is overhead caused by the switching
between userspace and os kernel space, as well as high memory overhead.
Using fork would have the same behaviour as something like apache prefork.
Handling a long running connection entails a process per connection, which
could mean an awful lot of processes.

Pretty much everything seems to be switching to async io based on some
event loop, as it allows a single process to handle requests from a large
number of connections, and long tunning but sparsely used connections don't
require holding processes open that are mostly doing nothing.

Based on what i see from the direction things are going in other languages,
just 'getting with the times' and switching to an event based model
probably makes the most sense.

Anyway, i think PHP really needs to be able to handle web sockets in core.

--000000000000718cb3059d19ef2f--