Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51037
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain macvicar.net from 97.107.131.220 cause and error)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <91.E1.59023.9ADC90D4@pb1.pair.com>
Date: Thu, 16 Dec 2010 00:42:14 -0800
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <2BF813E9-0314-4627-A278-601E357A8B01@macvicar.net>
References: <AANLkTi=ixWQkKovKYuLuQckDvkLQY2nYEyG6PJfZAn-G@mail.gmail.com> <C7.89.59442.304C70D4@pb1.pair.com> <1292411981.2128.2.camel@guybrush> <91.E1.59023.9ADC90D4@pb1.pair.com>
To: "jvlad" <dmda@yandex.ru>
Subject: Re: [PHP-DEV] Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded
From: scott@macvicar.net (Scott MacVicar)


On Dec 16, 2010, at 12:28 AM, jvlad wrote:

>>> No. Php if we talk about php with all its extensions is not =
threadsafe
>>> at
>>> all. Many of the extensions allocate static data and inherently
>>> non-thread-safe.
>>=20
>> PHP is, if compiled with ZTS/TSRM, thread-safe. Some libraries used =
by
>> some extensions might not be thread safe, but basically all "usually"
>> used ones are thread-safe. While it is a bit complicated as some
>> libraries could either be compiled thread-safe or not or some might =
be
>> not thread-safe on specific systems ... but that's not PHP itself ;-)
>>=20
>> johannes
>>=20
>=20
> Dear Johannes,
>=20
> I'm not sure why you repeated what I stated in my post. So I'm =
repeating it=20
> after you too :)
> Yes, php core is developed with threadsafe techniques in mind, some=20
> extensions are safe too, and some extensions which are using 3rd party=20=

> libraries are definitely not safe.
>=20
> The only thing I'd kindly ask you to pay more attention to is using=20
> "usually" word together with "safe" in one sentence. In my opinion =
they=20
> should never be used both if we talk about production servers, or at =
least=20
> servers where crashes are not welcome.
>=20
> Just to illustrate the issue with "usually", do you consider openssl, =
a=20
> widely used php extension, as a "usually threadsafe" extension?
> If you do, please take a look at this page=20
> http://www.openssl.org/docs/crypto/threads.html and these words in=20
> particular:
>=20
> OpenSSL can safely be used in multi-threaded applications provided =
that at=20
> least two callback functions are set, locking_function and =
threadid_func.=20
> locking_function(int mode, int n, const char *file, int line) is =
needed to=20
> perform locking on shared data structures. (Note that OpenSSL uses a =
number=20
> of global data structures that will be implicitly shared whenever =
multiple=20
> threads use OpenSSL.) Multi-threaded applications will crash at random =
if it=20
> is not set
>=20
>=20
> Do you think any locking function is implemented in openssl php =
extension?
>=20

In PHP a SSL_CTX is per thread and is not shared across other threads so =
it isn't an issue. We don't need to implement any openssl locking =
functions.

An example of non-thread safe is gettext it relies on the locale which =
is per process and not per-thread.

PHP itself at the core is thread safe. As Johannes said most common =
modules are too.

- Scott