Hi Chris,
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Christopher Kohlhoff Sent: Wednesday, September 28, 2005 6:36 PM To: boost@lists.boost.org 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