Re: [AD] proposal: al_sleep()

[aj <aj@xxxxxxxxxx>]

At 08:55 AM 2/01/2004 +0100, you wrote:
> On Fri, 2004-01-02 at 08:48, aj wrote:
> > >  And I still haven't found any reason why I would want the
> > >sched_yield behavior - it just causes the CPU to heat up for no reason
> > >in idle Allegro programs.
> >
> >
> > sleep(1)  on win32  tends to sleep approx 10 unless 
> the  timeBeginPeriod(1)
> > is set.
> > so unless the user or allegro uses the  timeBeginPeriod(1)  the user is 
> not
> > going to get 1ms sleep, but 10ms.
> > this will cause sluggish response.
> > on faster and ever faster CPU's, where we demand more processing, sleep
> > 10ms is a very long time.
> >
> > (use of timeBeginPeriod(1) also has some side effects, so if allegro is to
> > implement it, these side effects must be considered).
> >
> > yeild_timeslice()  is not supposed to be used to sleep your app...  its 
> all
> > about allowing other apps to run if they want.
> > if your trying to sleep your app then use sleep(>0).
> > so i think yeild_timeslice() is still a very important function..    how
> > you call it  ie al_sleep(0) is still a good idea.
> >
>
> Ok, the question is - if I'm in a loop where I don't want to give up a
> timeslice - would I call yield_timeslice in it?


no.  other apps will get CPU anyway, coz of multi-tasking....  calling 
yeild_timeslice is "playing nice"  you dont have to play nice, you can be 
bastard, and the shedular will  allocate CPU as it wants..  your app does 
not take responsibility for the system;  it takes responsibility for itself 
only, and if you know your app does not need CPU then call sleep(>0).


>  Maybe Allegro was meant
> to be used with a non-preemptive OS, so yield_timeslice() would be
> important.



allegro *IS* used on multi-tasking OS's.. 99% of the time, there is little 
DJGPP/DOS usage..  so yeild_timeslice() is intended to be used for exactly 
what the OS designers wrote it for... yielding, not sleeping.



> But on the 2 OSes where yield_timeslices() currently is
> implemented as stated in the docs, there is preemptive multithreading.


preemptive multi threading  can and does, take the CPU away from your app 
when you least expect it.

example...  a cross intersection, cars arrive at odd time,  a set of 
traffic lights is like preemptive multi threading.. everyone is forced to 
stop on red, and go on green.
this basically annoys everyone who has to stop...  were a round-a-bout   is 
like yield, everyone yields to each other, no-one gets annoyed, and traffic 
moves more efficiently.


> So if I want 100% CPU, I don't call yield_timeslice.


correct.


>  If I have an idle
> loop,


yes,   and if you know you probably will not need CPU for X milliseconds, 
then you should call  Sleep(X)  but be aware that X's minimum value is OS 
dependant.
and you will have to consult the OS's documentation on its minimum sleep time.


>  I call it, and want CPU to drop to 0. So my patch always improves
> things.


i have not read your patch, i was simply commenting on  the "still haven't 
found any reason why I would want the sched_yield behavior".

i dont think i was anti-"whatever your saying"  i was adding comment that 
might help someone to understand the differences.


i just thought of another example...  what if you have several threads 
running.. in your own app,  and you want  all of them to be using 100% CPU, 
but individually you want them to yield to each other at specific points in 
your code... i suppose you should use signals and such, but yeild might 
also be useful.




aj.