[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 dick at ximian.com.

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

--- shadow/80063	2006-11-27 05:06:11.000000000 -0500
+++ shadow/80063.tmp.1296	2006-11-27 19:26:47.000000000 -0500
@@ -1,14 +1,14 @@
 Bug#: 80063
 Product: Mono: Runtime
 Version: 1.2
 OS: GNU/Linux [Other]
 OS Details: 
-Status: NEW   
-Resolution: 
-Severity: 
+Status: RESOLVED   
+Resolution: NOTABUG
+Severity: Unknown
 Priority: Normal
 Component: io-layer
 AssignedTo: dick at ximian.com                            
 ReportedBy: pawel.sakowski at mindbreeze.com               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
@@ -58,6 +58,27 @@
 Expected Results:
 Reissuing the sleep after EINTR if necessary, always giving timestamp
 difference of at least 4000 ms (+- system clock inaccuracies).
 
 How often does this happen? 
 Always. The actual time varies between 500 and 610 ms.
+
+------- Additional Comments From dick at ximian.com  2006-11-27 19:26 -------
+Sending SIGQUIT to the mono runtime causes it to deliberately
+interrupt sleeps (and other waits).  If you send another signal that
+is caught (but not consumed) by the runtime the sleep should be
+resumed properly.  For example, add this to your test:
+
+  static void sig_handler(int sig) {
+        Console.WriteLine("Got signal {0}", sig);
+  }
+
+  static void Main() {
+    Mono.Unix.Native.Stdlib.signal(Mono.Unix.Native.Signum.SIGQUIT,
+sig_handler);
+
+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.