On 2013-01-17, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
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]
I don't think so. Posix says for alarm(2), for example,
The alarm() function shall cause the system to generate a SIGALRM
signal for the process after the number of realtime seconds specified
by seconds have elapsed."
That's normative; there is an informative note which says
The term "realtime" here and elsewhere ( sleep(), times()) is
intended to mean "wall clock" time as common English usage, and has
nothing to do with "realtime operating systems".
I don't know about you, but my clock on the wall doesn't stop running
when my computer is asleep!
Many use cases for this facility refer only to time
that passes when the machine is running.
I was trying hard to think of one - what's an example?
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
Ah, I didn't know that. I'd only seen run-at-time in a comment
somewhere describing it as FSFmacs!
Looking at the source, I suspect it doesn't work - I'll experiment and
check when I'm at home.
However, if it doesn't work, then looking at the source shows that it
will be a very simple lisp patch, so I can easily do it in .emacs .
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta