Re^3: pipe fork win32

[bulk88]

in reply to Re^2: pipe fork win32
in thread pipe fork win32

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.

[BrowserUk]

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?

[bulk88]

Marshall was complaining about an abnormally long sleep. While you are correct that sleep never guarantees a maximum time, only a minimum time, there must be a reasonable standard to which sleep must be expected to return control on a normal system. If you specify 1 second and got 4 seconds (Marshall's time), and there are no external reasons on that system (nice'd process at 100% CPU), then something else must be happening. A CPU timeslice is around 10-50 milliseconds on Windows http://support.microsoft.com/kb/259025, MS admits the time is updated only on a context switch http://msdn.microsoft.com/en-us/library/windows/desktop/ms724408%28v=vs.85%29.aspx. I just pointed out that on Windows systems with problematic clocks and scheduling, Perl's sleep likes to take many times longer than it should and there might be bug on why that happens. It is a known problem, http://www.nntp.perl.org/group/perl.daily-build.reports/2012/08/msg126306.html

# Failed test 4 -    right time (waited 1 secs for 3-sec alarm) at op/
+alarm.t line 55
op/alarm.t........... 
Failed 1/5 subtests 

# Failed test 2 -    right time (waited 5 secs for 3-sec alarm) at op/
+alarm.t line 35
op/alarm.t ........................................................ 
Failed 1/5 subtests 

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.

[BrowserUk]

on Windows systems with problematic clocks and scheduling,

Where do you get that &^*(&&*^*^ from? The failing tests you mention are Perl's failures not those of the OS.

Blaming the OS for those failures is like driving drunk, stoned and blindfolded and blaming the car for the crash.

div