Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82196
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54D7F5D5.4050808@gmail.com>
References: <CALW=WED82x9i0ea4MMuM3jkPknaBCmBPWExUyRKTDz-MPzif8g@mail.gmail.com>
	<54D7F5D5.4050808@gmail.com>
Date: Mon, 9 Feb 2015 02:02:29 +0200
Message-ID: <CALW=WEC1SqJRMCKXZfu8Ds5ob3LXN-5tzVW67pRVHmVpEg8fMA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] uWSGI experimental plugin for implementing a
 WSGI/PSGI/Rack-like interface for PHP
From: ua.san.alex@gmail.com ("S.A.N")

2015-02-09 1:48 GMT+02:00 Rowan Collins <rowan.collins@gmail.com>:
> On 08/02/2015 22:48, S.A.N wrote:
>>
>> Hi internals.
>>
>> I really hope that in the future PHP 7, there will be new server API.
>> May be you interested to know about them, here is the link, I am not
>> the author of development:
>> https://github.com/unbit/uwsgi-phpsgi/
>>
>> But the problem is that in PHP there are no standards for such interfaces.
>> Now it is implemented like this:
>>
>> <?php
>>
>> function application($env)
>> {
>>   return ['200 OK', ['Content-Type' => 'text/plain'], 'Hello, world!'];
>> }
>>
>> ?>
>>
>> I think this is a good opportunity to review the old interface ($_GET,
>> $_POST, ...) and start using the API internal HTTP module.
>>
>> This all breaks backward compatibility, not $_GET, $_POST, ...
>> But this WSGI SAPI will used only new PHP code (not PHP legacy base).
>>
>> This is a good opportunity to create something new and not be backward
>> compatible.
>>
>> What do you think about this?
>
>
> The problem with creating an event-based API for PHP is that you don't just
> have to rethink superglobals, you have to rethink absolutely everything that
> currently acts as global state:
>
> - global variables
> - static variables within functions
> - class static variables
> - dynamic settings (ini_set etc)
> - globally registered callbacks (set_error_handler, spl_autoload_register,
> etc)
> - the counters of include_once() and require_once()
> - any function which implicitly fetches data based on some previous action
> (e.g. libxml_get_errors)
>
> If the language is not itself multi-threaded, all of these become
> arbitrarily shared once per thread the server spins up and reuses. If it
> *is* multi-threaded, you have another set of headaches about how both the
> engine and the userland can share and synchronize.
>
> Not that I don't like the idea, but it's a huge project, with potential for
> profoundly affecting the language.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

You're right, but there is no threading issues.
One worker synchronously execute requests, but may run parallel many workers.