Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108255
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <c2848f32-b06f-6711-8cbd-7fcba263ce29@gmail.com>
Date: Sun, 26 Jan 2020 16:49:47 -0500
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <98A11C8F-6B51-4774-A2F6-6B6C7311180B@newclarity.net>
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>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] Add viable long running execution model to php 8
From: mike@newclarity.net (Mike Schinkel)

> On Jan 26, 2020, at 4:31 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> It's not about timing out, as such, it's about starting with a fresh =
state each time a request comes in from the web server. So the =
long-running script can't just "opt out of time outs", it's got to be =
launched by something other than a request - in existing =
implementations, it's basically started as a command-line script, and =
then handles the networking itself.

Other than an assumption that we would use the same infrastructure we =
have for existing PHP requests, which is not an assumption I am making, =
why is it not technically possible to have an HTTP request be the =
trigger vs. a command line script?  The long running process actually =
would return an HTTP status code letting the caller know if it was =
started or not.

Alternately an API called from a regular request could do the starting =
of the long-running process.

In that case we would of course need a regular request to be able to =
restart the long-running script too via an API, if needed.  Or even =
terminate it.

> In general, though, this is an interesting concept: keep each request =
separate, but have a "master process" (initialised when the server =
starts, or by something similar to a fork() call in a normal request) =
that all requests can explicitly share things with.

Yes. Thank you for acknowledging.

> 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. =20

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.


-Mike=