Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82259
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <CALW=WEBJ+fSTA8x1ADjPbUNGy_sjrZhN7krDnoi8-Up=3wFx-g@mail.gmail.com>
References: <CALW=WED82x9i0ea4MMuM3jkPknaBCmBPWExUyRKTDz-MPzif8g@mail.gmail.com> <54D7F5D5.4050808@gmail.com> <CALW=WEC1SqJRMCKXZfu8Ds5ob3LXN-5tzVW67pRVHmVpEg8fMA@mail.gmail.com> <54D7FEBA.1070304@gmail.com> <CALW=WEBJ+fSTA8x1ADjPbUNGy_sjrZhN7krDnoi8-Up=3wFx-g@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Mon, 09 Feb 2015 10:41:13 +0000
To: "S.A.N" <ua.san.alex@gmail.com>
CC: internals <internals@lists.php.net>
Message-ID: <860EABC1-CAFF-4FD1-8C59-2F2E06C9D8B8@gmail.com>
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 9 February 2015 02:16:53 GMT, "S.A.N" <ua.san.alex@gmail.com> wrote:
>2015-02-09 2:26 GMT+02:00 Rowan Collins <rowan.collins@gmail.com>:
>> 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]
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>Yes, option (B) is more like.
>
>Let me show in your PHP code, how the option that I like, we have the
>actual application work that way in the pecl-event module, we are
>satisfied, it is convenient and very fast for PHP.

Yes, I can see it working well for specialised uses - you can simply not use those aspects of the language that don't make sense. But for it to be a mainstream part of the language, it needs to play nicely with other parts of the language, and that's where I see it being a complex and painful change.

Regards,
-- 
Rowan Collins
[IMSoP]