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
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.
*/
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.
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