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.
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.
Pete
