[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