Re: [AD] rest and yield_timeslice

[Elias Pschernig <elias@xxxxxxxxxx>]

On Tue, 2004-07-20 at 04:33 -0700, Chris wrote:
> Elias Pschernig wrote:
> >>That's supposed to say *isn't* fully dependable, btw. In either case, 
> >>nanosleep seems to be the proper way to sleep in Unix. Allegro uses 
> >>enough "standard hacks" IMO, and I think it would be nice to use a 
> >>proper implementation where we can.
> > 
> > Nah, it sounds somehow like it does too much. Remember, we primarily
> > want to give up CPU with rest, and the nanosleep docs talk a lot about
> > real time mode and busy waiting.. all sounding like it does something
> > too much. "usleep" would be just what we want, but since it's not posix,
> > select is perfect.
> 
>  From what I remember hearing, select waits for a file descriptor to 
> become available.. and by using select like we do causes it to wait for 
> stdin (or maybe stdout? I don't remember what was said). Small waits are 
> fine, but when you go for longer waits it'll be interrupted but 
> stdout/stdin events.
> 
> That's how I interpreted what I heard, anyway. If that turns out to not 
> be the case, then I suppose it won't matter too terribly. I just think 
> nanosleep would be a cleaner solution.
> 

No, it will just wait, since the first parameter is 0 and therefore
there are no descriptors to wait on.

> > Well, to me, the highest priority is the cleaner and more logical API.
> > And I still don't see the problem with changing rest.. there's hardly
> > any code who would use negative numbers for rest, especially since the
> > docs don't even allow that. rest() might as well be freezing up with
> > them right now, or going back to the past, which would be the logical
> > thing to do with negative numbers probably :)
> 
> Heh, that's true. I'm just trying to minimize potential problems though. 
> I don't see a need for rest times in the billions, and negative numbers 
> can be delt with easilly enough.
> 
> Besides, it'd break the declaration: rest(long time)  :P
> 
> Though we seem to have drifted away from how rest(0) should behave. ;) 
> As I mentioned, I think the behavior of rest is primarilly to pause 
> until the next function call, with a secondary concern being lowering 
> CPU usage. If you don't believe this is the case, then I would propse 
> that a function be made that would do high precision busy-looping. I 
> could create the function itself easilly enough if there was a 
> high-presicion timer in Allegro. And I could do that as well, but only 
> for Windows, Unix, and maybe DOS.
> 

I'm also not too sure about high-precision though. If we e.g. use us or
ns for it - it would be inconsistent with the ms in rest. But well,
let's worry about that once there's a patch to implement it :)

> Actually, yeah.. this seems to be the perfect opportunity to start 
> prefixing. What you could do is rename rest to al_rest that takes an 
> unsigned int parameter. Have an inline rest(long) that calls al_rest for 
> compatibility (and I would also suggest this inline call filters out 
> negative times to be 0). Although I'm not completely convinced that 
> rest(0) shouldn't return immediately, I will concede that a function 
> named rest is better suited to resting the process as opposed to 
> something named al_wait which would do busy-looping.
> 

Yep, I think we should have a backwards-compatibility file, which
defines all the old symbols to new ones. It should be included with
Allegro 4.2, but not be enabled by default.

Would putting it as include/allegro/oldapi.h sound like a good idea? For
now, it would only contain the old rest. For the 4.2 release, it will
contain all the functions, with the prefix #defined away, as well as all
deprecated material.

-- 
Elias Pschernig