I vaguely recollect hearing or reading someone else say something similar a long time ago, but I know it has never been true -- at least not since the long gone days of cooperative multithreading -- so I'd really like to know where the idea comes from?

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The sleep(1) in the client is what I tried before and it did not work. I think that there are some flaky things having to do with Win XP. After a re-boot this worked. I am completely flabbergasted why it did not work before.

There is stochastic involved. Two identical calls (expected to give the same result) can give different results. What I understand is the problem in the implementation of the Windows API and not in the Perl implementation.

In some cases the processes running the Perl interpreter are blocking (coming in an unwanted state).

Sometimes the problem is not solved by restarting the Perl interpreter. Is there some missing initializations in the Perl interpreter?

In some rare situations the total system (not just the process running the Perl interpreter) is affected, and must be restarted. Sometimes it even must be restated using power down/up. The isolation between processes and the operating system in Windows has some weakness?

The questions which worries me are:

Is it advisable to use the Perl's fork() emulation in Windows in “production” code?

Is it enough to run the test of Perl modules just once or how many times are they needed to be run?

Fork in general is fine, although most/all CPAN modules will leak resources with fork unless they specifically say they are psuedo fork safe (have a CLONE method or use mg_dup magic). Doing a kill on a child absolutely isn't safe and never will be completely safe see ( https://rt.perl.org/rt3/Ticket/Display.html?id=88840 ). Previously doing a kill on the child the moment the parent starts the child (why would you do that in production code?) would hang the parent interp later in the parent interp's execution. I am not doing a kill anywhere. I need to, and have the child exiting voluntarily.

Is it advisable to use the Perl's fork() emulation in Windows in “production” code?

Windows just doesn't do "fork" very well. Threads are the way to go with Windows, but that model is more complex. BrowserUK knows a lot about how to do this on Windows. I would say that emulate behavior X on Y, often doesn't work out that well.

I previously had been working on recovering data from a damaged SD card. I managed to get 1,500+ files off of this thing. But Windows was not "happy" and I had to re-boot many, many times during this process. I also do not know how, but there do appear to be some kinds of errors that can mess Windows XP up in weird ways. I do not know why.

Perl sleep on windows in a VM or 100% CPU usage or C debugger breakpoints, or bad driver that likes lock all the CPUs and then spin sleep for too long to freeze the PC can cause an overflow in Perl's sleep, and then only a random Windows message (mouse move, repaint, idk what else, but there WILL be one, thx MS) will breakout of the sleep hang, see https://rt.perl.org/rt3/Ticket/Display.html?id=33096 causing the sleep to take more seconds than it should have. win32/win32.c#l2163 in perl.git for the offending code.

Firstly, this perl-internals implementation bug is totally unrelated to the issue of whether "sleep work on multiple threads".

Secondly, the "bug" in that RT isn't a bug.

It basically says that sleep doesn't guarantee to return exactly when you asked for it to. But I'm not aware of any OS that gives such a guarantee, It is documented to sleep for at least the number of seconds requested.

It does not say that it will break out of a broken device driver, or debugger, nor VM, nor preempt a higher priority CPU-intensive thread or process.

I'm really confused why you thought it was relevant to raise that non-related, non-issue in this context?

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

And that system has been having a randomly failing alarm.t since, forever I think.

If a GUI program that is not doing anything CPU or I/O intensive randomly stops responding to mouse movement for 4 seconds, it would be completely unacceptable. Clearly the OS manufacturer (Microsoft) did not design the OS to ever do that, so other app specific causes should be considered. I couldn't tell whether Marshall's scripts output was done with his ping backticks delay or whether with a sleep(), I assumed sleep() since he claimed he rebooted and sleep() starting working accurately again.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other