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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
