Hi Andrew, --- Andrew Schweitzer <a.schweitzer.grps@gmail.com> 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?
Yes.
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 error operation_aborted). Cheers, Chris