Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82204
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.53 as permitted sender)
Message-ID: <54D7FEBA.1070304@gmail.com>
Date: Mon, 09 Feb 2015 00:26:34 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals <internals@lists.php.net>
References: <CALW=WED82x9i0ea4MMuM3jkPknaBCmBPWExUyRKTDz-MPzif8g@mail.gmail.com>	<54D7F5D5.4050808@gmail.com> <CALW=WEC1SqJRMCKXZfu8Ds5ob3LXN-5tzVW67pRVHmVpEg8fMA@mail.gmail.com>
In-Reply-To: <CALW=WEC1SqJRMCKXZfu8Ds5ob3LXN-5tzVW67pRVHmVpEg8fMA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like
 interface for PHP
From: rowan.collins@gmail.com (Rowan Collins)

On 09/02/2015 00:02, S.A.N wrote:
> You're right, but there is no threading issues.
> One worker synchronously execute requests, but may run parallel many workers.

I'm not sure what you mean by this. I can see 3 ways of handling 
incoming web requests, as it affects PHP's threading:

A) The current "shared nothing" model: the web server may have multiple 
processes or threads, but each requested is executed in a completely 
separate global scope of PHP.
B) Each process or thread in the web server spawns an instance of the 
application; the application has a global state within that instance, 
and startup and shutdown code; the instance is sent multiple requests, 
but has no way to know if it is getting all the requests, half the 
requests, or one hundredth of the requests.
C) The web server executes the application once, which sets up its 
global state, and then spawns an internal threading model; each request 
is sent to a worker thread within PHP, which has to synchronise with 
other threads in order to access any aspect of global state.

I guess you are suggesting option (B), which is what I was referring to 
when I said that global state would be "arbitrarily shared" - if 
handling a particular request caused any global state to be changed, 
such as registering an error handler, it could affect anything from 0 to 
100% of subsequent requests, depending on how the web server is configured.

The code therefore needs to avoid relying on any such global state at 
all, which basically restricts you to a subset of the current language. 
For it to become the default way of running PHP, huge changes would be 
needed to adapt code to this new model.

The reason I mentioned threading is that under option (C), migration 
becomes a bit easier in some ways: you can move some things which are 
currently global state into an explicitly per-thread state, allowing old 
behaviour to be emulated; and you can leave other things in synchronized 
global state, like ini settings, solving the problem of "50% of my 
threads have a different error handler registered".

Regards,

-- 
Rowan Collins
[IMSoP]