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
