Re: [boost] [asio] what happens to outstanding operations when demuxer::interrupt called?

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-28 07:18:36

Hi Andrew,

--- 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?

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