what's the official position on apache threaded environments

php.internals

J. Adams

8 years ago
So what's the story with PHP and multithreaded environments these days? Does this statement on the PHP website still stand? http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2 Seems a bit archaic these days to eschew multithreaded environments, doesn't it? More specific questions: * is there any kind of authoritative list of PHP modules that are NOT threadsafe? If so, where might I find it? * What warnings, indications, failures, or errors, if any, might I encounter if I am experiencing undesirable behavior by using PHP in an event or worker environment? * Does anyone have any comment on the recommended means of acquiring PHP within Apache as described on the apache wki here: https://wiki.apache.org/httpd/php

Helmut Tessarek

8 years ago
On 2018-03-21 21:59, j adams wrote:
> So what's the story with PHP and multithreaded environments these days?
Unfortunately PHP was never and will most likely never be threadsafe as a module. (Yes, I know that there's the ZTS code, but hey, are you really serious about this?) I never understood why the core devs never switched to a threaded model, but I believe they never deemed it truly necessary. The ZTS threaded module has a few interesting approaches but fails in some other areas. To be honest, I suggest to use the fpm-cgi SAPI module with an Apache threaded environment.
> Does this statement on the PHP website still stand? > http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2
Sorry, didn't read it.
> Seems a bit archaic these days to eschew multithreaded environments, > doesn't it?
Yes, it is. Doesn't change the fact that PHP is not threadsafe.
> More specific questions: > * is there any kind of authoritative list of PHP modules that are NOT > threadsafe? If so, where might I find it?
No, there isn't. But if you run php via fpm, it doesn't really matter anyway.
> * What warnings, indications, failures, or errors, if any, might I > encounter if I am experiencing undesirable behavior by using PHP in an > event or worker environment?
I use an event MPM on my server with an fpm cgi module Cheers, K. C.
-- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */

Alice Wonder

8 years ago
On 03/21/2018 09:15 PM, Helmut K. C. Tessarek wrote:
> On 2018-03-21 21:59, j adams wrote: >> So what's the story with PHP and multithreaded environments these days? > > Unfortunately PHP was never and will most likely never be threadsafe as > a module. > (Yes, I know that there's the ZTS code, but hey, are you really serious > about this?) > I never understood why the core devs never switched to a threaded model, > but I believe they never deemed it truly necessary. > The ZTS threaded module has a few interesting approaches but fails in > some other areas. To be honest, I suggest to use the fpm-cgi SAPI module > with an Apache threaded environment.
I've been using zts w/ latest apache in threaded and have not found the issues, but I've heard Remi mention them and he generally knows all things truth from fiction when it comes to php. Is there a list somewhere of what the specific issues with using zts in multi-threaded apache are? What modules have known issues? I haven't found it.

Johannes Schlueter

8 years ago
On Mi, 2018-03-21 at 22:52 -0700, Alice Wonder wrote:
> Is there a list somewhere of what the specific issues with using zts > in multi-threaded apache are? What modules have known issues? > > I haven't found it.
PHP itself should be thread-safe, if there are bugs inside PHP itself we try to fix them. However: PHP links to tons of external libraries, some of them might not be fully thread-safe or make assumptions. An example for such assumptions, aside from obvious memory access issues, is around the current working directory: In a threaded environment all parallel handled requests are in the same process and there can be only one "current working dir" (cwd) per process. We have the VitualCWD to mitigate, but that doesn't control what happens inside an external libraries code. A list for that doesn't exist as verifying this is hard. Most mainstream things should be thread-safe, while even some C standard library features we use sometimes aren't thread-safe (i.e.  due to use of the global "errno" for returning error codes, protecting these needs tons of locks which can limit scalability a lot ... if there are thread-safe/re-entrable versions of such library calls exist we should use them, not using them is a bug on our side, maybe since the thread- safe API is "new" compared to our implementation or too system- specific) On the more philosophical reasoning PHP tries to isolate requests from each other. Whatever happens in one request should not impact the other requests. By relying on the operating system's process isolation we gain a boundary. A known example where this fails are some forms of recursion where we still reach stack overflows (way less situations than in the past, but still) On stackoverflow the operating system will terminate the process. In a per-process model this impacts only the failing request, in a threaded model hits all parallel threads. (and eventually the complete server, whereas in a per-process model one always has a super process watching and restating children) There had been attempts at different times by different folks Zend, Sun Microsystems, Microsoft etc. to improve this, but it never got mainstream trust. A bit different is having threads inside a single script run, there also has some work been done (-> pthreads) but often people decide to offload longer running tasks to external systems (microservices?) instead of building a single large system. So that also didn't go mainstream (while there still are use cases) johannes