From: BRIDGES Dick (Dick.Bridges_at_[hidden])
Date: 2005-09-30 16:18:46
> -----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,
> 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)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk