On Tue, Sep 02, 2003 at 06:21:44PM -0400, Peter Chen wrote: > On Tuesday, Sep 2, 2003, at 17:28 US/Eastern, Rocco Caputo wrote: > > >I have heard conflicting stories about whether the time shift is > >significant. Jeff Bisbee posted that systems based on UTC don't see > >shifts in time() when DST/Standard arrive. Matt Cashner is convinced > >that NTP prevents the problem from occurring. It's an area I admit > >knowing very little about, and I'm loath to bring down my development > >machine to simulate Daylight Savings/Standard time shifts, manually, or > >by tricking NTP. I've made some small changes, of perhaps five minutes > >either way, and discovered that times() does not behave as claimed. > > Perhaps I can ask the question slightly differently. Is it acceptable > for POE to fail to deliver sigchild because of a system time change?
No, it is not. Neither is it acceptable to consider the issue "resolved" when it has been patched for a single operating system. One part of the "signal reforms" (already in progress) is to re-enable %SIG handlers if the perl version is 5.8 or greater. Those versions introduce "safe" signals that reportedly don't dump core, so we won't need to work around SIGCHLD core dumps anymore. By the way, the page outlining these "reforms" has recently been updated. See http://poe.perl.org/?POE_RFCs/Signal_Reforms > Here is a simple way of illustrating this, start a process using > POE::Wheel::Run, then immediately set the system time backwards for two > hours. I have observed that in this case sigchild will not be > delivered until two hours later. This is somewhat of a nasty surprise, > wouldn't you say? Yes, it is very nasty and surprising. I'm looking forward to it being fixed, but I'm no longer holding my breath for a solution. Chris Fedde's report on the POSIX specification shows monotonically increasing clocks to be OPTIONAL. In RFC-speak, they MAY (not MUST) be implemented. While I would prefer if all operating systems implemented monotonic clocks, we cannot rely on them existing. At best we can catalog all the different monotonic clocks on every operating system we can get our hands on, and implement some highly portable interface to everything. Or we can look elsewhere for a solution. Consider Perl 5.8.0's signals again. SIGALRM might be useful to create a constant timer tick. We can compare time() from one tick to another, and if the time jumps backwards (or forwards much more than the tick interval), the clock might be said to have shifted. I'd hazard a guess that a significantly larger set of operating systems support SIGALRM than monotonic clocks. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
