Re: [AD] rest and yield_timeslice

[Angelo Mottola <a.mottola@xxxxxxxxxx>]

Just come back from a 4 days trip and I've found tons of AD mails... 
nice to see Allegro development back in action!

> Though there's an important difference. When you do rest(x) where x > 
> 0, on platforms capable of course, you technically don't yield. 
> Yielding implies stopping _only if_ there's something else on your 
> priority level or higher that wants the timeslice. When you rest, 
> you're actually lowering the process's priority level so that it's on 
> par with the system idle process, if not lower (eg. completely 
> inactive), until another process restores it. However, when you yield 
> you keep your priority level the same.. you're merely put at the end 
> of the queue so other processes of equal or higher priority can use 
> the timeslice.

Hu. Actually rest() on most platforms (all unix-like expect BeOS) will 
call usleep I think. And this is a syscall; most kernels (all?) will 
reschedule on syscalls. 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. No priority is changed AFAIK.
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.

> Now.. Windows seems to do something like this for Sleep:
>
> set_process(lowest_priority);
> do {
> } while (wait_time > 0);
> set_process(restore_priority);

Then Win32 should be handled separately, not just calling a sleep 
function.
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. So why use another function (yield_timeslice) 
when you can reuse this one?

--
Angelo Mottola
a.mottola@xxxxxxxxxx
http://www.ecplusplus.com