bug-gettext
[Top][All Lists]
Advanced

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

[bug-gettext] [bug #43404] gl_locale_name_default() thread issues on OS


From: Bruno Haible
Subject: [bug-gettext] [bug #43404] gl_locale_name_default() thread issues on OS X
Date: Sun, 16 Sep 2018 15:05:52 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0

Update of bug #43404 (project gettext):

                  Status:                    None => Wont Fix               
             Assigned to:                    None => haible                 
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

Indeed, I see two threads being created when single-stepping over the first
call to CFLocaleCopyCurrent().

The stack traces from the post you referenced (attached here as threads.txt,
for reference) show that
1. your program invokes libintl,
2. libintl invokes CoreFoundation,
3. CoreFoundation invokes libdispatch, which is the "Grand Central Dispatch",
see https://apple.github.io/swift-corelibs-libdispatch/

Is CoreFoundation justified in doing that? Well, from an excerpt of CFLocale.c
(attached) you can see that the CoreFoundation comes with its own type system;
the type system needs to get initialized; and the dispatcher is used to
guarantee once-only initialization. So, they use the dispatcher in really
low-level parts of macOS. That's what macOS is like, today.

Is libintl justified in invoking CoreFoundation? Well, CoreFoundation is the
only API in the system where you can reliably retrieve the user's language
preferences. Either you do internationalization seriously, then you *must* use
CoreFoundation. Or you implement a stub (which is what they have in their
libc), which looks at environment variables but ignores what the user has set.
For GNU gettext, I made the choice to take it seriously.

Should your program invoke libintl? Only you know.

I'm closing this as "Won't fix", because of the reasons stated above.

So, I'm not seeing many ways to work around it:
- Your program could stop using setlocale() - if it's not meaning to obey the
user's settings.
- Your program could delay the setlocale() call until after fork().
- Maybe you can formalize a notion of programs that take their notion of
"current locale" from elsewhere than from the user's settings, or where "the
user" is a different concept? How would a program declare that it is such a
beast?

(file #45023, file #45024)
    _______________________________________________________

Additional Item Attachment:

File name: threads.txt                    Size:2 KB
File name: CFLocale.c                     Size:0 KB


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?43404>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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