Re: POE and the time

Your post is an excellent counterpoint.  I agree in theory with all your
comments.  But in practice, things are broken.  POE should not depend on =
a
stable, monotonic time(2) because there is zero guarantee of such.

On 15-Dec-2012 Chris Fedde wrote:

> The only way that the
> program would know that time has changed is if it has two sources to
> compare.=20

Modern systems do have 2 sources to compare.  See timer_gettime(2)
CLOCK_REALTIME vs CLOCK_MONOTONIC (for Linux).  Win32 has SetTimer et al

> If the program decides to take action because it has detected a time ch=
ange
> then  it must have an array of logic to decide what special behaviors t=
o
> apply for all of the various ways that the change could have occurred.

This is why I propose the 'clock-skew' psuedo-signal.

> Trying to correct for bad admin behavior is better done at the social l=
ayer
> than at the technical one.

POE does not currently act usefully during clock skew.  If time jumps bac=
k, then
the queue blocks until time(2) gets back to the previous value.  This pre=
cludes
any events being delivered unless there is new FD activity, and user code=
 can
not react usefully.  Saying "but that shouldn't happen" is not very usefu=
l.  I
agree it shouldn't happen, but it does happen and must be able to handle =
the
situation gracefully.

-Philip