Re: PSA: Clock drift and pkgin

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> So even though we added one tick, you can still get two timer events
> in much closer proximity than a single tick as far as the process is
> concerned.

Certainly.  I think that's unavoidable without resetting the timer
inside the signal handler, or hard realtime guarantees (which are Not
Easy).

> And we probably do need to talk about the timer expiration and
> rearming as separate from signal deliver and process scheduling.

There are plenty of reasons user code running the signal handler may be
delayed from the time the timer is supposed to tick.

But without the timer ticking as requested, I don't think the rest
matters nearly as much.  When even an _unloaded_ machine can't get the
ticks it asks for, something is wrong.  A machine which gets that
overloaded just from delivering 100 signals to a mostly-trivial signal
handler per second, well, I doubt NetBSD runs on anything that weak.

> And from a program point of view, that is what really matters in the
> end.  If the program really wants a minimum amount of time before the
> next timeout, it needs to do the request for the next time event at
> the processing point, not something kernel internal which happend
> very disconnected from the process.

Agreed.  ITIMER_REAL in the form I've been arguing for is of little
help to a process that wants timer ticks separated by a hard minimum
interval as seen by the signal handler.  At least when using
it_interval to get repeated signals.

But then, so is every other ITIMER_REAL I've ever used.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B