[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daiki Ueno
Subject: Re: [bug #43404] gl_locale_name_default() thread issues on OS X
Date: Mon, 13 Oct 2014 10:06:36 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)


Forwarding to the mailing lists to get more feedback; the original
report can be found at <http://savannah.gnu.org/bugs/?43404>.

(I've changed the tracker configuration so that all reports will be sent
to the mailing list hereafter.)

Peter Eisentraut <address@hidden> writes:

> Something in libintl calls setlocale(), which calls gl_locale_name_default(),
> which calls CFLocaleCopyCurrent() on OS X.  Our analysis shows that
> CFLocaleCopyCurrent() spins up an additional thread, which causes all kinds of
> chaos in signal handlers and forked processes.  Here is the full analysis:
> http://www.postgresql.org/message-id/address@hidden
> Clearly, this is a somewhat special application, compared to all the
> single-threaded, single-process programs out there, but if adding gettext
> support to a server causes it to crash in random ways, that doesn't seem
> nice.
> The original change in gettext/libintl is
> d4fd77b3f57a386b63083a7246ae5808510ac072.
> Later in the above thread, a patch is proposed to move the Core Foundation
> calls into a subprocess, which you might be interested in.

That sounds like an interesting idea.  Perhaps gl_locale_name_default
could use the pipe/fork trick around the Core Foundation calls, for
single-threaded consumer (using pthread_is_threaded_np).  Is this kind
of change acceptable in Gnulib?

By the way, the issue reminds me of:
though it is a different (multi-threaded consumer) case.

Daiki Ueno

reply via email to

[Prev in Thread] Current Thread [Next in Thread]