| Re: [AD] rest and yield_timeslice |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Angelo Mottola wrote:
Just come back from a 4 days trip and I've found tons of AD mails...
nice to see Allegro development back in action!
Yeah. Hopefully we can keep it up. :) Though we do badly need developers
that use Windows.
Hu. Actually rest() on most platforms (all unix-like expect BeOS) will
call usleep I think.
Actually, currently they call nothing. They do a busy wait that calls
yield_timeslice. Previously however, they used select. My and Elias
talked this over the other night/morning and we came to the conclusion
that nanosleep would be a better function to rest with. It's
POSIX-compliant unlike usleep, it's more flexible, and under certain
situations can be more accurate than other rest functions.
So when you call usleep(x) with x > 0, the
system will create a timer for the process (lasting x), put the process
in a wait queue on a global sleep semaphore, that will timeout when the
timer stops, removing the process from the wait queue. Oh, and while
reentering userland, the kernel will reschedule, giving CPU to other
non-waiting processes.
Okay, so it's something like this:
sleep_program();
wait_time();
restore_program();
As I said before, I believe something like this is completely ineffient
for games. Since rescheduling can make your program wait up to 10ms, I
think resting 0ms should be 0ms instead of 0-10ms. 1-10 = ~10, 11-20 =
~20, etc.
As you can imagine, usleep(0) is just a special case of this; with a
value of 0, the process is almost instantly removed from the wait queue,
but the reschedule has already taken place.
But the thing is, I don't think it should've been put in the queue if
you know you're going to immediately restore it. Unix provides
sched_yield() to yield the timeslice instead of relying on resting for
0ms, and Allegro should follow suit. However with Allegro, we need as
platform independant behavior as possible, and relying on the OS's sleep
function isn't a good idea since it can vary from 0ms to 10ms to up to
30ms(!), so it should return immediately. Most applications can take the
hit and not really suffer.. however for games it means the difference
between 30fps, 100fps, or more. Resting up to 30ms when they ask for 0ms
is a very bad idea, IMO.
What I'm saying here is that rest() by definition will sleep for x
milliseconds, and since it's not supposed to be a busy waiting, it WILL
yield on most platforms.
If it actually rests, yes (x > 0). But if you're not waiting (x <= 0),
it shouldn't yield or reschedule at all.
So why use another function (yield_timeslice)
when you can reuse this one?
Because the two serve two different functions. One rests when you have
nothing to do (and when you rest for <= 0ms, you obviously have
something to do), the other plays nice and shares the CPU with other
programs.
- Kitty Cat