Re: itimers and timer-func.el's `run-at-time' clash regarding the current time / zero interval
>>>> "nix" == nix <nix(a)esperi.org.uk>
writes:
> OK, but does your patch really implement F-N I-R, or just a
> very close approximation on systems that are running sanely?
nix> It implements fires-very-soon (i.e., `now' for all intents
nix> and purposes) instantly-repeats --- although I haven't
nix> touched the repeat behaviour. (All I needed was for
nix> fires-very-soon to not give a seemingly-gratuitous error.)
nix> Fires-very-soon pretty much equals fires-now, because you
nix> can't get any closer without a hard realtime OS.
uhm, I meant to put more emphasis on "sanely". I understand the
pragmatics, what I'm interested in is suppose you've got a program
like say Gnus that loves to lock itself up in tight loops that last
for an eternity (ie, small integral number of seconds), can you be
sure that by the time the timer gets started, Real Soon Now won't be
in the past? I realize that is totally counter to normal practice in
our industry :-), but is it physically possible?
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.