2015-02-09 1:48 GMT+02:00 Rowan Collins <rowan.coll...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
