Re: [AD] WIP 4.1.15 and CVS freeze

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Fri, 2004-07-23 at 15:22 +0200, Evert Glebbeek wrote:
> On Friday 23 July 2004 15:06, Elias Pschernig wrote:
> > Since we agreed that there will be another function with higher
> > precision which can be used to do more exact waiting, and "rest" will be
> > there to have a way to give up CPU, the rest(0) behavior and
> > yield_timeslice deprecation is settled I guess.
> 
> I'm not sure I like the logic of rest(0) == yield_timeslice.
> If I'd want to yield the remainder of the current timeslice, I'd rather 
> call a function called yield_timeslice() than a function called rest() 
> with argument 0... just personal preference though.
> 

Well, after the discussion about it, to me it appears that if rest() is
there to wait as accurately as possible, then rest(0) should do nothing.
If rest() is there to give up CPU, rest(0) to yield is logical. Since we
want rest() to give up CPU (we have no other function to do that), rest
(0) is logical, and there's no need for yield_timeslice.

> > Changing rest(long) to rest(unsigned long) makes a lot of sense in my
> > opinion, and will not break old programs (negative numbers never were
> > allowed), so I'm tending to just apply it, and then work on updating the
> > GUI to use rest instead of yield_timeslice.
> 
> There's no d_rest_proc, is there? In that case, will you changethe behavior 
> of d_yield_proc(), or depricate that too and add a new function to rest 
> for a specified amount of time?
> 

No, the behavior will be exactly that of 4.1.14 (That is, I leave it to
Angelo how it should behave on OSX, BeOS and QNX). Instead of
yield_timeslice, which waits 1ms in Windows, 1us in linux, and either 10
or 30 ms in OSX/BeOS/QNX in 4.1.14, there will be a call to rest
(AL_YIELD_TIME), where the constant is defined to 1 for Windows and
Unix, and possibly more on the 3 mentioned OSes.

-- 
Elias Pschernig





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/