setlocale may not be SMP safe

[Steven Levine]

This issue was encountered for

​http://mantis.smedley.id.au/view.php?id=611

which includes exceptq .trp files that imply that the locale impelementation may not be SMP safe. Locale updates are SMP safe because they are serialized. However, accesses to global locale data such as is done at:

_output.c:827

zdot[1] = __libc_gLocaleLconv.s.decimal_point[0];

are not serialized. It seems that there is a small window in localeCommit between the time localeNumericFree() is invoked and __libc_gLocaleLconv.s.decimal_point is set where the pointer is NULL and an access by some other CPU will result in an exception.

[bird]

I don't think setlocale is guaranteed to global thread-safety while updating the global locale data. (See ​http://www.remlab.net/op/oss-lib-threads.shtml for instance.)

Currently lacking good read-write locks, I cannot do much better than making sure the pointer is never NULL and to avoid replacing strings with the same value (as I kind of suspect this could actually turn out to be). The race between someone reading the pointer and setlocale calling free on it is still present. Changes committed in r3915 (branch) and r3916 (trunk).

Marking this as fixed as the real fix here is implementing the newer locale APIs.

[bird]

r3936 fixes a bug in the default & C/POSIX monetary locale uncovered by these changes.