| Re: [AD] rest and yield_timeslice |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Elias Pschernig wrote:
Well, we follow the semantics of Sleep(), select/usleep, SDL, and
properly most other waiting functions out there. And we won't get less
inaccurate than before, since it actually was using a timer everywhere
util now except windows.
Of course we won't get less accurate, I just meant it won't be more
accurate than the system's sleep method.
Well, if you send a patch to add an al_get_ticks functions which is more
accurate than timers, I'd be all for including it.
I would make a patch for al_get_msecs, though the changes would need ot
be fairly extensive, but not hard. We'd have to extend the system_driver
vtable to supply a get_system_ms_count to return milliseconds (and
default on a timer if the system doesn't have one (and no, clock won't
work since that works on process time, not computer time).
But that's really a seperate issue. The issue really at hand is, should
rest(0) mimic yield_timeslice().
Yes, but from my view, where rest() is primararly there to give up CPU
for a certain amount of time, yielding behavior makes perfect sense for
0 as parameter.
I would disagree that rest is there to give up CPU time. Rest is there
to delay execution, since DJGPP's delay function was no longer useable
after installing the timer. The fact that it may give up the CPU is a
secondary concern.
And following the logic that rest is used for delaying execution,
delaying for 0ms should not delay at all, including the time for a
timeslice.
I can't think of single situation where someone would be handling a
variable rest time, and want rest(0) to behave like rest(10) (or worst
case, rest(30)) in terms of program speed. If you have a variable wait
time, you'll most definately want it as accurate as possible. And if you
have a static/controlled rest time, it shouldn't be hard at all to call
yield_timeslice in place of rest(0).
Your user above would be better off using a busy loop,
at least for small wait times.
But the wait times could be comparitively large too, durring which they
may want to reduce CPU usage.
Negative values to rest will be catched
by an ASSERT in rest, or even better, I'll make the parameter unsigned.
I would contest this move. Negative rest values should be treated as 0.
And if someone tried that traction algorithm with unsigned numbers, it
could easilly underflow and rest for a couple billion milliseconds (if
other things don't break first from such a high number).
We are trying to clean up the API though, at least a bit, for 4.2, and
Allegro has had some very bad design decisions already long before the
3.x versions - so that's never a reason to keep inconsistent or
unnecessary functions.
No, the reason to keep the "unnecessary" functions is so older Allegro
programs will still compile properly and without problems with newer
library versions (save a few deprication warnings). IMO, this is very
important for new Allegro users who find, or like looking for, old
source code.
And I'd even go as far as fixing things like the 0..63 value
range for RGB in 4.2.0.
And break practically every Allegro program in existance?
- Kitty Cat