# uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP - Thread: https://externals.io/message/82185 - Original archive: https://news-web.php.net/php.internals/82185 - Started by S.A.N on 2015-02-08T22:48:03+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #82185 — S.A.N — 2015-02-08T22:48:03+00:00 URL: https://externals.io/message/82185#82185 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: '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? --- ## #82195 — Rowan Collins — 2015-02-08T23:48:37+00:00 URL: https://externals.io/message/82185#82195 · In reply to: #82185 > 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: > > > 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] --- ## #82196 — S.A.N — 2015-02-09T00:02:29+00:00 URL: https://externals.io/message/82185#82196 · In reply to: #82195 2015-02-09 1:48 GMT+02:00 Rowan Collins : > > > […] > > > 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] > > > -- > > > You're right, but there is no threading issues. One worker synchronously execute requests, but may run parallel many workers. --- ## #82204 — Rowan Collins — 2015-02-09T00:26:34+00:00 URL: https://externals.io/message/82185#82204 · In reply to: #82196 > 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] --- ## #82210 — S.A.N — 2015-02-09T02:16:53+00:00 URL: https://externals.io/message/82185#82210 · In reply to: #82204 2015-02-09 2:26 GMT+02:00 Rowan Collins : > > > […] > > > 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] > > > -- > > > 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. This is a very rough and simplified code: request = $object->request; $this->response = $object->response; } public function open() { /* Routing by $this->request, may be auth and open $this->session (analog $_SESSION), or throw Exception. */ return $this; } public function run() { /* Run your business logic... */ return $this; } public function close() { /* Run finally logic, and cleaning output buffer */ $this->response->body = `ob_get_clean()`; return $this; } public static function init() { /* Application configuration as static class state */ `ob_start()`; set_error_handler(/*...*/); self::$db = new DBConnection; self::$redis = new Redis; self::$cache = new Cache; } } // Bootstrap, run configuration App::init(); // Handler WSGI (not multi-thread) function application(HTTP $object) { $app = new App($object); $app->open()->run()->close(); return [ $app->response->code, $app->response->headers, $app->response->body ]; } --- ## #82259 — Rowan Collins — 2015-02-09T10:41:13+00:00 URL: https://externals.io/message/82185#82259 · In reply to: #82210 >2015-02-09 2:26 GMT+02:00 Rowan Collins : > > […] >incoming > > […] >multiple > > […] >and > > […] >but has > > […] >or one > > […] >global > > […] >sent to > > […] >threads in > > […] >to when > > […] >a > > […] >of > > […] >all, > > […] >For it to > > […] >to adapt > > […] >becomes > > […] >currently > > […] >behaviour to > > […] >state, > > […] > >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] --- ## #82294 — S.A.N — 2015-02-09T17:40:48+00:00 URL: https://externals.io/message/82185#82294 · In reply to: #82259 2015-02-09 12:41 GMT+02:00 Rowan Collins : > 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. > The fact that the lack of native application server for PHP is often the reason for leaving the PHP developers to other languages and technologies. Let's see what others have in 2015: Python - WSGI Ruby - Rack Perl - PSGI JavaScript - JSGI Hack - HHVM PHP - No native application server in core. What discusses the PHP community? Remove or not to remove the PHP4 constructors and many other issues that do not add competitive ability PHP... I personally do not blame you :), just expressing his opinion developer who wants to use PHP and can use modern app server in core PHP. Thank. --- ## #82295 — Albert Casademont Filella — 2015-02-09T17:44:16+00:00 URL: https://externals.io/message/82185#82295 · In reply to: #82294 HHVM is a FastCGI interface, just like PHP-FPM is, I don't see your point here! > 2015-02-09 12:41 GMT+02:00 Rowan Collins : > > […] > 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. > > […] > > The fact that the lack of native application server for PHP is often > the reason for leaving the PHP developers to other languages and > technologies. > > Let's see what others have in 2015: > > Python - WSGI > Ruby - Rack > Perl - PSGI > JavaScript - JSGI > Hack - HHVM > > PHP - No native application server in core. > > What discusses the PHP community? > Remove or not to remove the PHP4 constructors and many other issues > that do not add competitive ability PHP... > > I personally do not blame you :), just expressing his opinion > developer who wants to use PHP and can use modern app server in core > PHP. > > Thank. --- ## #82304 — Rowan Collins — 2015-02-09T18:24:03+00:00 URL: https://externals.io/message/82185#82304 · In reply to: #82294 S.A.N wrote on 09/02/2015 17:40: > 2015-02-09 12:41 GMT+02:00 Rowan Collins : > > […] > The fact that the lack of native application server for PHP is often > the reason for leaving the PHP developers to other languages and > technologies. > > Let's see what others have in 2015: > > Python - WSGI > Ruby - Rack > Perl - PSGI > JavaScript - JSGI > Hack - HHVM > > PHP - No native application server in core. > > What discusses the PHP community? > Remove or not to remove the PHP4 constructors and many other issues > that do not add competitive ability PHP... > > I personally do not blame you :), just expressing his opinion > developer who wants to use PHP and can use modern app server in core > PHP. > The sentence you're replying to there is talking about existing implementations, on top of current PHP, with all the limitations that implies. My view on the general idea of changing the language so that eventually an event-based model could be the norm, is in an earlier reply: > 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] --- ## #82376 — Rowan Collins — 2015-02-10T12:26:18+00:00 URL: https://externals.io/message/82185#82376 · In reply to: #82304 Rowan Collins wrote on 09/02/2015 18:24: > S.A.N wrote on 09/02/2015 17:40: > > […] > > The sentence you're replying to there is talking about existing > implementations, on top of current PHP, with all the limitations that > implies. > > My view on the general idea of changing the language so that > eventually an event-based model could be the norm, is in an earlier > reply: > > > […] > potential for profoundly affecting the language. I just realised the double negative in that sentence may not be easy to understand, so just to make sure it's clear: I do quite like the idea, in general, but think it would require a major rethink of large parts of code. We need only look at PHP 6/Unicode for the risks involved in a well-intentioned feature with far-reaching impact on the language. I also think that an application server model without userland threads would be a mistake, because it would still be difficult to share anything meaningful between requests. That said, if someone wants to start collecting a top-level list of what would need to be changed, and suggesting how it might work, I'd be happy to contribute some ideas. Regards, -- Rowan Collins [IMSoP] --- ## #82384 — S.A.N — 2015-02-10T15:57:43+00:00 URL: https://externals.io/message/82185#82384 · In reply to: #82376 2015-02-10 14:26 GMT+02:00 Rowan Collins : > Rowan Collins wrote on 09/02/2015 18:24: > I just realised the double negative in that sentence may not be easy to > understand, so just to make sure it's clear: I do quite like the idea, in > general, but think it would require a major rethink of large parts of code. > We need only look at PHP 6/Unicode for the risks involved in a > well-intentioned feature with far-reaching impact on the language. > > I also think that an application server model without userland threads would > be a mistake, because it would still be difficult to share anything > meaningful between requests. > > That said, if someone wants to start collecting a top-level list of what > would need to be changed, and suggesting how it might work, I'd be happy to > contribute some ideas. Yes, I understand you correctly, thank you.