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

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Tue Nov 28 06:07:09 EST 2006


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

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

--- shadow/80063	2006-11-28 05:26:43.000000000 -0500
+++ shadow/80063.tmp.8376	2006-11-28 06:07:09.000000000 -0500
@@ -1,13 +1,13 @@
 Bug#: 80063
 Product: Mono: Runtime
 Version: 1.2
 OS: GNU/Linux [Other]
 OS Details: 
-Status: RESOLVED   
-Resolution: NOTABUG
+Status: REOPENED   
+Resolution: 
 Severity: Unknown
 Priority: Normal
 Component: io-layer
 AssignedTo: dick at ximian.com                            
 ReportedBy: pawel.sakowski at mindbreeze.com               
 QAContact: mono-bugs at ximian.com
@@ -102,6 +102,16 @@
 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.
+
+------- Additional Comments From lupus at ximian.com  2006-11-28 06:07 -------
+I think there are two issues here:
+first, the user should not use SIGQUIT: this is a runtime managed
+signal that should be only used for debugging deadlocks and livelocks
+and such (yes, the manpage wording is unfortunate, IMHO)
+second: we need the sleep to be interruptable to implement some
+required runtime behaviour (I guess Thread.Interrupt/Abort etc): this
+doesn't mean that the Sleep icall should terminate earlier than
+requested if we don't actually terminate or interrupt the thread.


More information about the mono-bugs mailing list