Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108253
To: PHP internals <internals@lists.php.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>
Message-ID: <c2848f32-b06f-6711-8cbd-7fcba263ce29@gmail.com>
Date: Sun, 26 Jan 2020 21:31:42 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <8E382251-AE41-4BD9-A5F8-135D11B9E10D@newclarity.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Add viable long running execution model to php 8
From: rowan.collins@gmail.com (Rowan Tommins)

On 25/01/2020 22:03, Mike Schinkel wrote:
> I'm not following the discussion 100% – more like 85% — but it seems 
> like what we might be saying is the need for a user-land 
> implementation of a long-running PHP request, one that does not timeout? 


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.


> Then we could look to prior art with GoLang channels where they "Communicate to share memory" and do not "Share memory to communicate."  IOW, add an API that allows a regular PHP page to communicate with a long-running page.  This would decouple and allow for better testing, and hopefully fewer hard to track down bugs.


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. 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.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]