GNU gettext - Bugs: bug #43404, gl_locale_name_default() thread...
You are not allowed to post comments on this tracker with your current authentication level.
bug #43404: gl_locale_name_default() thread issues on OS X
Submitter: | Peter Eisentraut <petere> | ||
Submitted: | Sat 11 Oct 2014 12:53:40 PM UTC | ||
Category: | End-user / runtime | Severity: | 3 - Normal |
Item Group: | None | Status: | Wont Fix |
Privacy: | Public | Assigned to: | haible |
Open/Closed: | Closed |
Mon 12 Nov 2018 07:50:25 AM UTC, comment #2: |
Noah Misch <noah> |
Sun 16 Sep 2018 07:05:52 PM UTC, comment #1: Indeed, I see two threads being created when single-stepping over the first call to CFLocaleCopyCurrent().
|
Bruno Haible <haible> |
Sat 11 Oct 2014 12:53:40 PM UTC, original submission:
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/20140915045114.GA1332666@tornado.leadboat.com
|
Peter Eisentraut <petere> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 7 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2018-09-16 | haible | Attached File | - | Added threads.txt, #45023 | |
Attached File | - | Added CFLocale.c, #45024 | |||
Status | None | Wont Fix | |||
Assigned to | None | haible | |||
Open/Closed | Open | Closed | |||
2016-11-27 | haible | Category | None | End-user / runtime | |
2014-10-11 | noah | Carbon-Copy | - | Added noah |
Powered by Savane 3.13-f8d8.
Corresponding source code
I can think of two ways gl_locale_name_default() could avoid making a
single-threaded process multithreaded and also avoid the user-visible semantic
changes of the workarounds you list:
1. If the process is single-threaded, pipe(), fork(), and have the child call
CFLocaleCopyCurrent(). Pass the result back in the pipe. Otherwise (the
process is already multithreaded), just call CFLocaleCopyCurrent() in the
process that entered gl_locale_name_default(), like today.
2. pipe(), fork(), and exec() a helper executable that calls
CFLocaleCopyCurrent() and passes the result back in the pipe.
(1) is better, since having a helper executable in a well-known location will
be too hard. Both have the problems of fork() in a process that may not be
expecting it, like unplanned SIGCHLD handler execution and duplication of
output buffered in stdio before the fork(). Perhaps one could plug all those
holes (block SIGCHLD, exit child with raise(SIGKILL)).