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 19:26:47.000000000 -0500 +++ shadow/80063.tmp.8096 2006-11-28 05:26:43.000000000 -0500 @@ -79,6 +79,29 @@ 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. + +------- Additional Comments From [EMAIL PROTECTED] 2006-11-28 05:26 ------- +If it's by design, that's IMO not the most fortunate design. This +issue bit me in the following scenario (simplified): + +while (true) { + Thread.Sleep(3*3600*1000); + InvokeBigMaintenanceTask(); +} + +Now, if I use SIGQUIT to inspect the process'es state, the maintenance +task gets invoked very prematurely, doing many things I didn't want to +yet done (thus the 3h sleep) and mangling the very state I was trying +to observe with SIGQUIT. + +I worked around this by reissuing the sleep if it, for whatever +OS-related reason, returns earlier than expected (as determined with +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. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
