Re: Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded
| From: | jvlad | Date: | Thu, 16 Dec 2010 10:20:53 +0000 |
| Subject: | Re: Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-51040@lists.php.net to get a copy of this message | ||
"Stas Malyshev" wrote
> Hi!
>
>> 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.
>
> ICU btw has some global stuff too.
I think it's clear that having any global stuff does not necessarily make
the code thread-unsafe.
Problem happens only if data can be modified in one thread while another
thread may access it.
For example you can safely have a lot of "thread-unsafe" things in MINIT and
MSHUTDOWN functions of your extensions.
The only thing you must follow is to have everything thread-safe in the
exposed API and in RINIT/RSHUTDOWN and all functions called in them.
> It's actually worse as it has one global which is set depending on current
> locale and never changed even if PHP process changes the locale (yes, ICU
> has dependency on system locale, go figure).
It's my only guess - this is because a correct sorting of words in some
languages requires such thing as decomposition and therefore it is
locale-specific, even though the words are written in unicode. See p2 in
Sorting http://en.wikipedia.org/wiki/German_alphabet
and ligatures in
http://en.wikipedia.org/wiki/French_alphabet
In the other hand, you may want to check some js implementations (like the
one in KDE) they use ICU Lite and all necessary functions are implemented on
top of the tables, perhaps they do not depend on the system locale.
-j