Re: [boost] [asio] how detect deadline_timer expired state?

From: BRIDGES Dick (Dick.Bridges_at_[hidden])
Date: 2005-09-30 16:18:46

Hi Chris,

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of 
> Christopher Kohlhoff
> Sent: Wednesday, September 28, 2005 6:36 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] [asio] how detect deadline_timer expired state?
> 
> 
> Hi Dick,

[snip] 

> I didn't add an expired() method so as to not make it easy write code
> with a race condition ;) (Although strictly speaking you could check
> the duration returned by expires_from_now() for the same effect.)

I haven't had time go to through the code so I didn't understand the
value returned by expires_from_now() when called on timer that expired
or had never been set.

> The problem with a hypothetical expired() method is that if it returns
> true it doesn't actually tell you whether the async_wait's handler has
> been delivered yet, i.e. the timer expired but the handler could be
> sitting in the demuxer's post queue.

Makes perfect sense now that you point it out.  State changes are now
recorded in the wait handlers - where the state is actually changed. %>]

> Another thing is that changing the timer's expiry time while there are
> unexpired async_waits has no effect on those waits. In fact I should
> change the documentation to make it clear that changing the 
> expiry time
> while there are unexpired waits is "undefined". This design decision
> was taken for efficiency reasons, i.e. to avoid having getting or
> setting the expiry time need to access a synchronised resource (e.g.
> the select_reactor).

I agree the documentation should be changed.  I experienced some of
that "undefined" behavior before I switched to the cancel/set
instruction sequence.  8)

[snip]

> Cheers,
> Chris

Regards,
Dick