[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gettext] [bug #43404] gl_locale_name_default() thread issues on
Re: [bug-gettext] [bug #43404] gl_locale_name_default() thread issues on OS X
Wed, 18 Feb 2015 12:33:11 +0900
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)
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.
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:
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.