Re: [AD] rest and yield_timeslice

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2004-07-19 at 18:16 -0700, Chris wrote:
> Elias Pschernig wrote:
> > On Mon, 2004-07-19 at 08:30 -0700, Chris wrote:
> >>And from what I've heard, select is fully dependable, either.
> > 
> > Using select() seems a standard way to sleep in unix, to me.
> 
> 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.

> > Well, I'd have committed it if there wasn't complaints of course :) The
> > reason why I want to change to unsigned is, negative values make no
> > sense. Designing an API so there is little room for errorneous
> > parameters (<0 in the case of rest) always seems to be a good idea.
> > Making <0 a documented valid value for rest seem to be a worse
> > alternative, as does just leaving it as undefined bahavior.
> 
> How does Win32's Sleep() handle negative numbers? Allegro's current code 
>   handles negatives just like 0, and I think it should stay that way 
> (again, if someone already uses signed math and plugs it directly into 
> rest currently negatives wouldn't wait and return almost immediately, 
> but if you changed to unsigned, that negative would suddenly become very 
> large and seemingly freeze the program.
> 
> > And in this case, there is not even a backwards compatibility problem,
> > other than possible warnings for passing signed variables, since <0 is
> > unspeecified in the docs so far.
> 
> I still think the best thing to do is to continue with the current 
> behavior unless there's an important reason to change it.
> 

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

-- 
Elias Pschernig