[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: |
Noah Misch |
Subject: |
[bug-gettext] [bug #43404] gl_locale_name_default() thread issues on OS X |
Date: |
Mon, 12 Nov 2018 02:50:25 -0500 (EST) |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 |
Follow-up Comment #2, bug #43404 (project gettext):
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)).
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?43404>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [bug-gettext] [bug #43404] gl_locale_name_default() thread issues on OS X,
Noah Misch <=