bug-gnulib
[Top][All Lists]
Advanced

[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: Pádraig Brady
Subject: Re: [bug #43404] gl_locale_name_default() thread issues on OS X
Date: Mon, 13 Oct 2014 10:42:49 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 10/13/2014 02:06 AM, Daiki Ueno wrote:
> Hello,
> 
> 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:
> http://lists.gnu.org/archive/html/bug-gettext/2013-11/msg00020.html
> though it is a different (multi-threaded consumer) case.

There are many consequences to having multiple threads,
so it's worth avoiding/isolating that where possible.

You mentioned it would be conditionalized on pthread_is_threaded_np
for performance I suppose, as threaded progs would already
have to deal with the consequences of a separate thread.
So races in pthread_is_threaded_np would only be a small
performance issue.

Seems like a good idea to me.

thanks,
Pádraig.



reply via email to

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