On Tue, Sep 02, 2003 at 12:23:45PM -0400, Peter Chen wrote: > sungo wrote: > > >Peter Chen wrote: > > > >>Is there any particular advantage of replacing ST_TIME w/ ST_ALARM? > >>ST_TIME uses the old system time based semantic. Isn't what we are > >>trying to do here simply to add a "delay" based semantic? How about > >>keeping ST_TIME and adding ST_DELAY? > > > >so, let me get this straight... we're proposing a rewrite of POE's > >internal timing mechanisms so that people who don't run ntp won't get > >screwed when they manually adjust the time on their system once a > >year? does this seem a little silly to anyone else? we're talking > >about adding lots of complexity for very little gain. at least in my > >mind. i say we tag the documentation with a big DONT DO THAT and move on. > > The issue is actually much more severe. If you reread the postings back > in April, you will find that the initial discovery came from a POE based > daemon failing to respond to any request after the system time was > adjusted. Subsequent investigation revealed that POE's internal timing > mechanism is vulnerable to system time adjustements (whether it is done > manually or by NTP). Depending on the actual adjustment, one of the > symptoms is that sigchild will cease to be delivered. One implication > is that any daemon that uses POE::Wheel::Run becomes unreliable. > > I believe Rocco understands this, and this is why he was looking into > using POSIX::times. The only catch is that his development platform is > FreeBSD and FreeBSD seems to have a strange implementation of > POSIX::times which is not monotonically increasing.
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. I discarded POSIX::times because in practice it's not guaranteed to be the right solution. I'm reluctant to implement solutions that don't entirely solve problems because they lead to much uglier solutions later. The POE::Pipe classes are pretty ugly inside beacuse they wrap system-dependent behaviors in a unified interface. I don't mind it there because pipe setup is a relatively infrequent activity. Montioring the system time happens several times a second in POE's innermost core. Doing ugly things there will hurt everybody, all the time. If POSIX specifies that times() must return monotonically increasing values, then I'm willing to live with FreeBSD (and who knows what other operating systems) being broken. They violate POSIX, they deserve it, and I can pin the blame elsewhere. On the other hand, if POSIX times() doesn't guarantee monotonicity---if that's even a word---then I'm not willing to rely on that behavior. Anyone have the POSIX specification handy? > IMHO, the goal is not so much to rewrite POE's internal timing mechanism > per se, instead the proposal is to supplement it with a "delay" based > semantic in addition to the exisitng "system time" based semantic. This > "delay" based semantic would allow sigchild to be delivered regardless > of system time changes. True. The change I have in mind is rather heavy-handed: revise the priorities (times) of all delays in the main queue whenever time shifts make it necessary. Hopefully the slowness of this operation will be more than offset (har) by the infrequency of its use. It will add some additional code in POE's innermost loop. Every iteration through select(), or whatever event loop is being used, will require some additional clock checks. That slowdown---more system calls in the hottest code path---can't be helped, though. POE 0.26 is a quarter of a year old. The time-shift compensation feature is stalled in a major way, so I'm taking it off the goals list for 0.27. This may mean the feature won't be available for the "standard time" shift (backwards) coming in October. That's a tough call, but I'd rather see a new POE release than to hold it off for another couple months. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
