timeouts and suspend
Julian Bradfield writes:
Now that even desktop computers are routinely suspended to RAM,
I'm
increasingly bitten by the sad fact that Linux sleep(2) and friends
appear to treat "real time" as "machine running time" instead of
"physical time".
What's sad about it? It's an arbitrary choice, embedded in the POSIX
standard AIUI.[1] Many use cases for this facility refer only to time
that passes when the machine is running.
I presume this also affects XEmacs?
Of course.
Where would be the right place to address this? (For example,
something like checking the time every timeout-granularity seconds
to see if it's changed and timeouts need to happen.)
The choice of whether CPU ticks or UTC is the appropriate clock must
be made by the application. UTC clocks are nominally supported by
`run-at-time'. If that isn't good enough for your application, file a
bug or RFE against that. (It's a bug if the clock is "much less
accurate" than its documented[2] precision. It's an RFE if the precision
is "too low" for your application.)
I'm generally sympathetic, but we need to be cautious about anything
that adds frequent system calls. (OTOH, having XEmacs itself make
that system call itself, possibly with user-configurable frequency,
would surely be an optimization over making all applications get the
wall time in every itimer.)
Footnotes:
[1] There was an intense discussion of these issues when Python
revised its support for various kinds of clocks about a year ago. I
wasn't directly involved, so have forgotten many details.
[2] If it's not documented in words, you lose -- the source is the
documentation.:-P
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta