Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108289
To: Rowan Tommins <rowan.collins@gmail.com>,
 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>
 <c2848f32-b06f-6711-8cbd-7fcba263ce29@gmail.com>
Message-ID: <fd2455d3-ce1b-c699-a372-cab2eef0f280@cubiclesoft.com>
Date: Tue, 28 Jan 2020 07:26:01 -0700
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120327
 Thunderbird/11.0.1
MIME-Version: 1.0
In-Reply-To: <c2848f32-b06f-6711-8cbd-7fcba263ce29@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Add viable long running execution model to php 8
From: thruska@cubiclesoft.com (Thomas Hruska)

On 1/26/2020 2:31 PM, Rowan Tommins wrote:
> 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,

WebSocket is a framing protocol over TCP/IP for long-lived (potentially 
hours), mostly quiet, two-way connections to a web server usually from a 
compliant web browser that tends to slowly use more and more RAM on the 
client for whatever reason.  My favorite example of WebSocket usage is 
lightningmaps.org - accurately triangulates lightning strikes using 
ground-based sensor stations thousands of miles apart.

People tend to write WebSocket servers in NodeJS partly because they 
don't realize that PHP can already do the same.  Example:

https://github.com/cubiclesoft/php-drc

In recent years, I've used PHP for a lot of non-web things.  In fact, a 
lot of my real PHP work these days is CLI-based usually running either 
as cron jobs or as installable at-boot system services via Service Manager.

I recommend reading libev's documentation regarding various "special 
problems."  PHP would be implicitly taking on a lot of complicated 
issues that even the authors of libev and libuv (NodeJS uses libuv) 
haven't entirely solved and then passing those issues onto users.  It 
would be important to at least point the various issues out to users in 
documentation.

I personally prefer to use userland isolated libraries even though it 
takes me slightly further away from the metal.  From my experience, 
libev and subsequently PECL ev are a more natural transition for 
existing socket code whereas Swoole/libuv basically demand a rewrite for 
little gain.  The only downside to using PECL ev is that its support for 
Windows is actually non-functional despite PECL generating DLLs.

WebSocket generally introduces network and processing overhead - HTTP 
headers and parsing for setup + framing protocol handling.  In many 
cases, a simpler "JSON blob per newline" approach works just as well (if 
not better) and can afford better isolation and performance models (i.e. 
not everything has to be WebSocket).  There are plenty of flaws inherent 
to the design of the WebSocket protocol itself (some are 
security-oriented) and so anything built on it shares those flaws.

WebSocket and WebRTC SAPIs could be an interesting direction to go in. 
I'm not opposed to the idea.  I do think though that people need to be 
far more reserved when it comes to writing TCP/IP servers than they are 
right now.  A lot of careful thought needs to happen prior to writing 
bind().  Network code is quite notably hard to get right and complexity 
multiplies with multi-OS/platform support.

-- 
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/