Locale handling was originally not thread safe. POSIX 2008 created a
parallel universe set of locale functions that are thread safe. Since
Perl 5.27.9, these are by default used by perl in threaded builds.
However, some C libraries, such as X, continue to use the original
functions. That means that those libraries don't see the locale as set
by Perl, and Perl doesn't see the locale set by these functions.
Perl does provide functions callable by XS to cope with this situation.
This commit changes Tk to use them. The thread calling Tk is changed to
use the locale handling functions used by the X library. As long as
only one thread in an application converts, the entire application
remains thread safe. (If more than one thread converts, the application
becomes non-thread safe, like it was during most of Perl's history.) It
is out of Tk's control if the application does this. The perllocale pod
gives appropriate cautions about this.
This is my best guess as to where the calls should go. But Slaven would know better. I want to make sure @Tux sees this
Locale handling was originally not thread safe. POSIX 2008 created a parallel universe set of locale functions that are thread safe. Since Perl 5.27.9, these are by default used by perl in threaded builds. However, some C libraries, such as X, continue to use the original functions. That means that those libraries don't see the locale as set by Perl, and Perl doesn't see the locale set by these functions.
Perl does provide functions callable by XS to cope with this situation. This commit changes Tk to use them. The thread calling Tk is changed to use the locale handling functions used by the X library. As long as only one thread in an application converts, the entire application remains thread safe. (If more than one thread converts, the application becomes non-thread safe, like it was during most of Perl's history.) It is out of Tk's control if the application does this. The perllocale pod gives appropriate cautions about this.
This is my best guess as to where the calls should go. But Slaven would know better. I want to make sure @Tux sees this