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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] @@ -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 [EMAIL PROTECTED] 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. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
