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?

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
[download]

# 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
[download]

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.

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.

---

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.

RIP Neil Armstrong

div