On Fri, Oct 10, 2014 at 09:14:38PM -0400, Peter Eisentraut wrote:
> On 10/10/14 8:24 PM, Noah Misch wrote:
> > Here's an implementation thereof covering both backend and frontend use of
> > setlocale(). A setlocale() wrapper, pg_setlocale(), injects use of the child
> > process where necessary.
>
> Would such a change not be better in gnulib itself?
Good question. It would be nice to make the change there, for the benefit of
other consumers. The patch's setlocale_native_forked() assumes it never runs
in a multithreaded process, but libintl_setlocale() must not assume that. I
see a few ways libintl/gnulib might proceed:
1) exec() a helper program to run CFLocaleCopyCurrent(). Distributing that executable alongside libintl and locating
itat runtime is daunting.
2) Audit the CFLocaleCopyCurrent() code to see if it will, in practice, run reliably in a fork of a multithreaded
process. (That conclusion could change without notice.) Use the setlocale_native_forked() technique.
3) Don't change libintl_setlocale(), but add a libintl_setlocale_nothread() for single-threaded consumers to adopt.
Eachconsumer will need to modify code. libintl has a lean API; I expect adding this would be controversial.
Among those, I would probably adopt (2). We know much about the process
conditions in which pg_setlocale() will run, so placing the workaround in
PostgreSQL erases the problem of (2). I'm inclined to stick with placing the
workaround in PostgreSQL, but there are fair arguments on both sides.
