This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
Refactor locale mutex setup
authorKarl Williamson <khw@cpan.org>
Mon, 30 Nov 2020 16:46:34 +0000 (09:46 -0700)
committerKarl Williamson <khw@cpan.org>
Tue, 8 Dec 2020 13:44:20 +0000 (06:44 -0700)
commitd9e22c6a8a05aab7fffdbf810f74ddfcb4efd752
treee07ddc2c28e07f5e4f7b7b100265627111a89e41
parent8609fe004ed37605b00f517feb6e9c8eb127952c
Refactor locale mutex setup

This was prompted by my realization that even on a locale thread-safe
platform, there are functions we call that may not be thread-safe in
that they return their results in an internal static buffer, which may
be process-wide instead of per-thread.  Tomasz Konojacki++ briefly
looked at Windows source code for localeconv() and this indeed did
appear to be the case.

If we thought a platform was thread-safe, no locale mutexes were set up,
and instead the calls in the code to lock were no-oops.  This would lead
to potential races, the most likely candidate being localeconv().  None
have been reported, at least as far as we know.  Likely that function
isn't called frequently.  This would be true on both Posix 2008 and
Windows platforms, except possibly for FreeBSD, which may be the only
platform that we support that has a localeconv_l() function, which is
supposed to be immune from this issue..

The solution adopted here is to test for all the possible functions that
the Perl core uses that may be susceptible to this, and to set up the
mutex if any are found.  Thus there won't be no-ops where there should
be a lock.
makedef.pl
perl.h
perlvars.h