Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101996
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 84.19.169.162 cause and error)
Message-ID: <1521724088.2237.21.camel@schlueters.de>
To: Alice Wonder <alice@librelamp.com>, internals@lists.php.net
Date: Thu, 22 Mar 2018 14:08:08 +0100
In-Reply-To: <360598cf-f723-1279-0a95-3c5055447fe8@librelamp.com>
References: 
	<CADbOR2jGipMjHGNYHO-hqkcYo_mNovJoxnuMB+RvPqe3PdMhTg@mail.gmail.com>
	 <421fae6f-d6ba-1990-d3d8-9ac236313cea@evermeet.cx>
	 <360598cf-f723-1279-0a95-3c5055447fe8@librelamp.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] what's the official position on apache threaded
 environments
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

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