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