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

[Daiki Ueno]

Noah Misch <address@hidden> writes:

> gl_locale_name_default() failure is relevant to a
> libintl_setlocale(LC_x, "") locale change, though.

Good point, right.

>> 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

This solution looks reasonable.

At first, I thought that the implicit thread creation in CF and the
consequent crashes at fork() are a problem that we should avoid in
gnulib and libintl.

However, according to this article:
http://objectivistc.tumblr.com/post/16187948939/you-must-exec-a-core-foundation-fork-safety-tale
CF seems to deliberately register a pthread_atfork() handler to cause a
crash in unsupported situation.

So, now I have a feeling that our workaround might be overkill.
Although I actually don't know how much CF helps locale detection, if it
is not significant, perhaps we could make CF optional and/or
conditionalize the calls to CFLocale.

Regards,
--
Daiki Ueno