fork() erroneusly enables locales on Windows

[schroeer]

I am observing strange behaviour when using the Morbo server of Mojolicious on Windows under the latest Perls.

• Windows 11 with German settings.

• No language/locale related settings in environment.

• Same behaviour observed on two different computers.

• Strawberry Perl 5.42.0.1 and Mojolicious 9.42 shows the problem shown below.

• Strawberry Perl 5.40.2.2 with the included distributions has the same problem.

• Strawberry Perl 5.38.4.1 and Mojolicious 9.42 works fine.

• My first bug report: locale problem mojolicious/mojo#2302

• A similar issue has been described here: Perl as service locale issue StrawberryPerl/Perl-Dist-Strawberry#270

• I have not found a simpler way to trigger the wrong behaviour.

Steps to Reproduce
This Mojolicious app.pl:

use Mojolicious::Lite -signatures;

get '/' => sub ($c) {
    my $f = 1.5;
    $c->render( text => "\$f is $f and 1/2 is " . ( 1 / 2 ) );
};

app->start;

Start the app with morbo ./app.pl.

Description

$f is 1 and 1/2 is 0,5 is shown in the browser.

This is wrong. Note the missing decimal places and the comma as the decimal separator.

Expected behavior

$f is 1.5 and 1/2 is 0.5 is shown in the browser.

This works correctly in all configurations when the app is started with ./app.pl daemon instead of morbo.

It works correctly also with morbo under Strawberry Perl 5.38.4.1 and Mojolicious 9.42.

[xenu]

Minimal reproducer without Mojolicious:

print 1/2 unless fork;

So basically, forked children act as if use locale was active.

This is definitely a bug, not sure if it's on our side, or in UCRT. I will look into it.

[xenu]

When thread-local locales were implemented, a call to thread_locale_init() was added to threads.pm, but it wasn't added to win32_start_child(), which is the function executed at the beginning of pseudofork on Windows. Windows fork() emulation is implemented using threads, but it doesn't use threads.pm.

This could be easily added, but my worry is about the (documented) surprising behaviour of locales in threads - new threads get their locale set to "C". I think replicating this behaviour in fork() would be even more confusing.

I think ideally forked() child should have the same locale as its parent.

[sisyphus]

Could fork() be implemented on Windows such that it doesn't rely on perl's threading capability ?

[xenu]

I can think of three ways to implement fork():

1. What we're doing now.
2. What Cygwin does. It's fragile (see FAQ), it's complicated and it requires an external runtime. That said, it emulates fork way more accurately than we do.
3. NtCreateProcess() - this a real fork, but it's undocumented and to use it properly you need to call a set of even more obscure, undocumented APIs. It's fragile, it breaks some assumptions that Windows userland has about programs.