Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108243
To: internals@lists.php.net
References: <CAMuFt-6V24w6o8-hoPeRETCtfW25OtQ3KwdYprpYoQqpNQ2OsQ@mail.gmail.com>
Message-ID: <3ca6d665-1a4f-8f7a-c82a-2e899f2e8df1@gmail.com>
Date: Sat, 25 Jan 2020 16:32:04 +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: <CAMuFt-6V24w6o8-hoPeRETCtfW25OtQ3KwdYprpYoQqpNQ2OsQ@mail.gmail.com>
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 24/01/2020 09:29, Robert Hickman wrote:
> PHP is pretty unusual in comparison to most web platforms nowadays as it
> runs each request in an isolated process. Web development in other
> languages is instead based around a long lived set of processes, which
> serve multiple requests.
>
> That model has advantages in that it is very easy to cache data in process,
> and should be simpler in theory to get good performance as all code can be
> loaded into memory once during startup. Autoloading therefore goes away.


Hi Robert,

Could you share some more thoughts on what you are thinking of here? I'm 
guessing you're thinking along the lines of an "event-based" system, 
where each request is a function call, rather than a whole script 
invocation?

PHP is sometimes described as having a "shared nothing" architecture - 
everything is wiped out at the end of each requests - so perhaps one way 
to look at this is to propose a "shared something" version.

The first question is _what_ we want to share. We already have sharing 
of compiled code, with OpCache bundled since 5.5, and the pre-loading 
feature in 7.4 could make autoloading redundant for many applications. 
What we can't share natively is any data structures, resources like 
database connections, or other global state like set_error_handler.

The second question is _how_ it should be shared - what would it look 
like to the user? For instance, should _simultaneous_ requests be able 
to share state? That might mean making them explicitly aware of other 
threads, or running them all on one thread but in a series of 
asynchronous functions (as I understand it, that's how node.js works).

It's definitely an interesting question to explore, though.

Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]