Noah Misch <n...@leadboat.com> 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
