Re: [AD] public thread API

[Elias Pschernig <elias@xxxxxxxxxx>]

On Thu, 2008-08-07 at 09:07 +1000, Peter Wang wrote:
> > Oh, something else:
> > 
> > int al_cond_timedwait(ALLEGRO_COND *cond, ALLEGRO_MUTEX *mutex,
> >                       const ALLEGRO_COND_TIMEOUT timeout);
> > 
> > What about using "double timeout", and specifying it in seconds?
> 
> This reminds me of a similar decision in the events API that we
> discussed, which I forgot to implement.  We should adopt the same
> solution for al_cond_timedwait as for the events function.

Hm. In current SVN, I found this:

bool al_wait_for_event_timed(ALLEGRO_EVENT_QUEUE *queue,
   ALLEGRO_EVENT *ret_event, float secs)

> At any rate, it should be an absolute timeout as al_cond_timedwait()
> *needs* to be called in a loop.  With relative timeouts you're
> obliged to keep track of how long al_cond_timedwait() took
> and subtract that for the next iteration of the loop.

Well, 

ALLEGRO_COND_TIMEOUT cond_timeout;
al_cond_timeout_init(&cond_timeout, timeout);
while(!check_condition() &&
    !al_cond_timedwait(cond, mutex, &cond_timeout)) {}

vs.

double end_time = al_current_time() + timeout;
while(!check_condition() && al_current_time() < end_time)
    al_cond_timedwait(cond, mutex, end_time - al_current_time());

The second version seems more explicit to me, no extra struct, no extra
function call, and a direct time comparison instead of a return value. 

But no strong preference, and I might be missing something..

-- 
Elias Pschernig <elias@xxxxxxxxxx>