Re: [AD] rest and yield_timeslice

[Chris <kcat@xxxxxxxxxx>]

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

Okay. Ther's one last thing though, before I let this go. select isn't 
gauranteed to rest the process according to my docs, whereas nanosleep is.

> 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 :)

By high-presicion, I meen better-than-10ms granularity. :)

> 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.

I agree with Evert that 4.1.15 is too soon, and I'd also say 4.2 is as 
well. Because remember, once we create al_set_gfx_mode (or its 
equivilant) that's it. We won't be able to change the parameters later 
on, aside from making al_set_gfx_mode_ex.

My advice would be this.. create the oldapi.h header, but start it empty 
and include it _by default_. Have a define ALLEGRO_DISABLE_OLD_API that 
would force that header to not be included for those that don't want the 
old counterpart functions hanging around. Then as we make new functions 
(eg. al_rest from rest), we move the old function into the oldapi 
header. This gives us the advantage of taking the time to plot out and 
think about a new API (one that's not simply prefixed, but much cleaner 
than currently) so that it would be more robust and compatible, as well 
as maintaining backwards compatibility durring the transition.

Then when the time comes (when we have properly rewritten the API 
functions, not simply renamed them), we'll just have the oldapi header 
not included by default.. leaving us with the clean API.

> 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.

Again, this is a bad idea if for nothing else other than that we'd have 
the same problem as we do now, except without name clashing.  The API 
will still be poor by today's standards with little room to fix things.

- Kitty Cat