Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85687
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <551CEDF6.7090408@lerdorf.com>
References: <CA+kxMuSvxRq-AvjQSBUc-FiYdTrD_1X2SuQtjWRjTwAbcwWRoA@mail.gmail.com>
	<551CEDF6.7090408@lerdorf.com>
Date: Thu, 2 Apr 2015 12:01:02 -0400
Message-ID: <CAJhmKHkyJN8E7RGOo19bYVQ5JjPaJcW8iJ+ad4VPzGiGC54+uA@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Dan Ackroyd <danack@basereality.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b2e44b0490fc00512bff04f
Subject: Re: [PHP-DEV] Deprecate setlocale?
From: keyurgovande@gmail.com (Keyur Govande)

--047d7b2e44b0490fc00512bff04f
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 2, 2015 at 3:21 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> On 04/01/2015 09:15 AM, Dan Ackroyd wrote:
> > Hi,
> >
> > I'd like to get people's feedback for the idea of making setlocale be
> > either deprecated and to be removed eventually or just increasing the
> > warning level against people using it.
> >
> > The short version of why we should do this is that setlocale breaks
> > things. It is a process wide operation, that is not thread safe on
> > most platforms. Although people use it to alter the way strings are
> > output, it also breaks libraries that are assuming that they are
> > running in a "C" locale.
>
> The PHP setlocale() wrapper can be made threadsafe in a portable manner
> via newlocale()/uselocale(), so that part isn't an issue. Someone just
> needs to write the code for the threaded SAPIs. It hasn't been a high
> priority due to how few people use non-Windows ZTS mode so far.
>
> Obviously within the same process there may be issues with changing a
> locale to something unexpected by subsequent code, but that is really a
> bug in that code then. If some library function expects and only works
> in the "C" locale, it should make sure it is in that locale before doing
> anything and then restoring the locale back appropriately. And with a
> bit of symbol trickery libraries that do actually call setlocale to
> change it and restore it can be made to use our newlocale/uselocale
> thread-local locale mechanism.
>
> setlocale() is used quite a bit and for non-threaded, which is the bulk
> of php usage, it tends to work quite well. It is annoying that it is
> process-wide and as you noted that can cause issues, sure, and that the
> current implementation isn't threadsafe, but it isn't something that is
> technically unsolvable. Rather than throwing our hands in the air and
> just pulling the rug out from under people using it, we should take a
> look at fixing the problems associated with it instead.
>
> -Rasmus
>
>
To Rasmus's point, here's a PR for HHVM to provide a thread-safe setlocale
implementation: https://github.com/facebook/hhvm/pull/4736/files

It should be fairly easy to refactor the thread-safe-setlocale.(h/cpp)
files for Zend.

--047d7b2e44b0490fc00512bff04f--