From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-28 07:18:36
--- Andrew Schweitzer <a.schweitzer.grps_at_[hidden]> wrote:
> The doc seems to imply that if demuxer::reset() and
> demuxer::run() are called again, then outstanding operations
> will in fact be executed. Is this true?
> Are there general design philosophies out there for handling
> things that happen way too late because the loop was paused?
Not pausing the loop in the first place? ;)
> One system I worked on just fired all the stale timers at
> once, which I think what asio does. In the system I worked on,
> no effort was made to check whether the timer was firing hours
> too late.
> Would it be reasonable to modify the timer completion handler
> to accept the amount of time "overdue" the current call of the
> handler is? This would at least allow the handler to check,
> but maybe that's too complicated.
In this case you could compare the expires_at() value of the
timer with the current time, or perhaps check how far negative
the value expires_from_now() is.
> There appears to be no general way to toss all work
> outstanding, is this correct? I assume that's because it's
> hard to do so portably for all services.
Yep, for example you can't get access to Windows overlapped I/O
operations. Although, if you never call demuxer.run() again the
work is effectively tossed (but also leaked).
> On the other hand, it seems like maybe just deleting all your
> deadline_timer or stream_socket objects would cause them all
> to be cleaned up.
If these objects have async operations against them then the
handlers for these operations will still be dispatched (with the
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk