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

[Noah Misch]

On Wed, Feb 18, 2015 at 12:33:11PM +0900, Daiki Ueno wrote:
> 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.

That pthread_atfork() handler detects one bad situation.  Detection is
helpful, but fixing the problem after detection remains difficult.  The
handler doesn't even detect effects on sigprocmask() and other non-CF
interfaces.  The fork workaround is stronger on both of those points.

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

It's worth considering.  If libintl stopped calling gl_locale_name_default(),
individual programs could restore today's behavior with something roughly as
simple as 'setenv("LANG", gl_locale_name_default(), 0)'.  If libintl were
introducing gl_locale_name_default() code for the first time, I would favor
exposing the functionality that way instead of calling the code implicitly in
libintl_setlocale().  However, I don't know if the benefit from changing this
now is worth the pain of a user-visible behavior change compared to earlier
versions.  I would not take that risk, personally.  The fork workaround is
much less likely to break applications that work nicely today.

Thanks,
nm