Re: [bug #43404] gl_locale_name_default() thread issues on OS X

[Noah Misch]

On Sat, Jan 31, 2015 at 04:58:52PM +0900, Daiki Ueno wrote:
> Sorry for long delay.  I've refreshed the patch.
> 
> Changes from v1 are:

This patch looks good.

> Noah Misch <address@hidden> writes:

> >> +  if (close (fd[1]) < 0)
> >> +    {
> >> +      close (fd[0]);
> >> +      goto done;

> > Though orthogonal to this patch, libintl_setlocale() and
> > libintl_newlocale() would do better to return 0, not "C", after such
> > an internal error.
> 
> I'm skeptical that this is the right thing to do.  POSIX says:
> 
>   Upon successful completion, setlocale() shall return the string
>   associated with the specified category for the new locale. Otherwise,
>   setlocale() shall return a null pointer and the global locale shall not
>   be changed.
> 
>   A null pointer for locale shall cause setlocale() to return a pointer to
>   the string associated with the specified category for the current global
>   locale. The global locale shall not be changed.
> 
> I read this as: setlocale() returns NULL only when changing the locale
> (not querying the locale).

I agree with your conclusion about setlocale(LC_x, NULL), but
libintl_setlocale(LC_x, NULL) does not call gl_locale_name_default().  It
passes the request to setlocale_single(), which has no failure mode beyond
what the libc setlocale() might have.  gl_locale_name_default() failure is
relevant to a libintl_setlocale(LC_x, "") locale change, though.

> Based on the approach taken by PostgreSQL, proposed by Noah Misch

Incidentally, PostgreSQL decided not to do the fork.  Instead, PostgreSQL now
detects when setlocale() made it multithreaded.  It then directs the user to
set a locale environment variable, thereby working around the problem.  That
diagnostic will become less relevant over time once your patch becomes part of
GNU gettext.

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=894459e59ffa5c7fee297b246c17e1f72564db1d

Thanks,
nm