Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:51040 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 98577 invoked from network); 16 Dec 2010 10:20:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Dec 2010 10:20:58 -0000 X-Host-Fingerprint: 95.31.13.88 xdmitri2.static.corbina.ru Received: from [95.31.13.88] ([95.31.13.88:29276] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 84/C1-19877-808E90D4 for ; Thu, 16 Dec 2010 05:20:57 -0500 Message-ID: <84.C1.19877.808E90D4@pb1.pair.com> To: internals@lists.php.net References: <1292411981.2128.2.camel@guybrush> <91.E1.59023.9ADC90D4@pb1.pair.com> <2BF813E9-0314-4627-A278-601E357A8B01@macvicar.net> <4D09D39F.4060301@sugarcrm.com> Date: Thu, 16 Dec 2010 13:20:53 +0300 Lines: 37 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Posted-By: 95.31.13.88 Subject: Re: [PHP-DEV] Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded From: dmda@yandex.ru ("jvlad") "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