[Mono-bugs] [Bug 80063][Nor] Changed - Signals abort Thread.Sleep

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by pawel.sakowski at mindbreeze.com.

http://bugzilla.ximian.com/show_bug.cgi?id=80063

--- shadow/80063	2006-11-27 19:26:47.000000000 -0500
+++ shadow/80063.tmp.8096	2006-11-28 05:26:43.000000000 -0500
@@ -79,6 +79,29 @@
 and it will sleep for the full 4 seconds.
 
 Btw, DateTime.Milliseconds returns "the milliseconds component of the
 date represented by this instance", ie a value between 0 and 999, not
 the number of milliseconds since the epoch.  For that you need a new
 TimeSpan(datetime.Ticks).TotalMilliseconds.
+
+------- Additional Comments From pawel.sakowski at mindbreeze.com  2006-11-28 05:26 -------
+If it's by design, that's IMO not the most fortunate design. This
+issue bit me in the following scenario (simplified):
+
+while (true) {
+  Thread.Sleep(3*3600*1000);
+  InvokeBigMaintenanceTask();
+}
+
+Now, if I use SIGQUIT to inspect the process'es state, the maintenance
+task gets invoked very prematurely, doing many things I didn't want to
+yet done (thus the 3h sleep) and mangling the very state I was trying
+to observe with SIGQUIT.
+
+I worked around this by reissuing the sleep if it, for whatever
+OS-related reason, returns earlier than expected (as determined with
+DateTime.UtcNow). However, I would expect the runtime to do that for me.
+
+Also please note that the current behavior doesn't match the
+documented behavior of either SIGQUIT (according to the man page) or
+Thread.Sleep. So IMO if it's not addressed otherwise, this behavior
+should be documented.