On 9 February 2015 02:16:53 GMT, "S.A.N" <ua.san.a...@gmail.com> wrote: >2015-02-09 2:26 GMT+02:00 Rowan Collins <rowan.coll...@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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
