10:20 a.m.
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".
I presume this also affects XEmacs?
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.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:30 a.m.
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
9:50 a.m.
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
12:20 p.m.
Julian Bradfield writes:
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".
My understanding is that a lot of people hanging out around POSIX
interpret "wall clock" as "while the computer is running". But that
may just been the high-precision clock folks.
I was trying hard to think of one - what's an example?
Interrupting an infloop. Printing out a progress report.
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.
Wouldn't be surprised. The itimer code is quite old.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:45 p.m.
On 2013-01-17, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
> I was trying hard to think of one - what's an example?
Interrupting an infloop. Printing out a progress report.
Nope. To interrupt an infloop, you should be measuring process virtual
time (SIGVTALRM) , not realtime. Interrupting a deadlock, perhaps.
I also can't think of any progress reports that I want at running-time
intervals rather than realtime intervals!
It occurs to me that with a bit of luck, the problem will not be an
issue, because the auto-save timer fires every three minutes, which
should cause other timers to be expired, and that's often enough for
my purposes. (I was worried that my VM alarm facility would tell me 9
hours later about something I had to do that morning!)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:46 a.m.
Julian Bradfield writes:
On 2013-01-17, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
> > I was trying hard to think of one - what's an example?
>
> Interrupting an infloop. Printing out a progress report.
Nope. To interrupt an infloop, you should be measuring process virtual
time (SIGVTALRM) , not realtime.
That depends on what resource you're conserving, and/or on your
heuristic for deciding that she's a witch and needs to be burned. If
it's something related to user attention, realtime is relevant. If
it's something related to asynchronous I/O, realtime is relevant. If
it's CPU time, virtual time is the obvious criterion. (N.B. I mean
that "obvious criterion" is a much stronger claim than "relevant.")
I also can't think of any progress reports that I want at
running-time
intervals rather than realtime intervals!
Again, it's a heuristic for a certain amount of processing, delivered
at intervals convenient for the human operator. For CPU-bound tasks,
I suppose the virtual time might be preferred in many applications,
but even that depends on how important convenience for the operator is.
It occurs to me that with a bit of luck, the problem will not be an
issue, because the auto-save timer fires every three minutes, which
should cause other timers to be expired, and that's often enough for
my purposes. (I was worried that my VM alarm facility would tell me 9
hours later about something I had to do that morning!)
OK, but if you decide not to do anything about it, would you file an
issue briefly explaining what you've learned so far? (I'd do it, but
you know more about this than I do at the moment.)
Thanks!
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:27 p.m.
On Thu, Jan 17, 2013 at 5:20 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
My understanding is that a lot of people hanging out around POSIX
interpret "wall clock" as "while the computer is running". But that
may just been the high-precision clock folks.
There is some controversy over that point, but some do interpret it
that way. Hence CLOCK_BOOTTIME, CLOCK_REALTIME_ALARM, and
CLOCK_BOOTTIME_ALARM on Linux. See:
http://lwn.net/Articles/428176/
http://lwn.net/Articles/429925/
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4326
days inactive
4328
days old
6 comments
3 participants
participants (3)
-
Jerry James -
Julian Bradfield -
Stephen J. Turnbull