Sorry for quoting that much, but I am moving a private conversation back to the list. The question was about a small test: int main() { asio::demuxer d; { printer p(d); } d.run(); return 0; } which exited with access violation, and I wanted to know whether cancelation in the destructor would help. Christopher Kohlhoff schrieb:

--- Roland Schwarz <roland.schwarz@chello.at> wrote:

...

I you prefer and if you think others also could benefit from my questions, I also can continue on the list.

I don't mind either way :)

...

So embedding the cancel into printers destructor would help?

No, that's not actually the problem. In fact, the deadline_timer destructor already cancels the operation.

The problem is that the completion handler (whether cancelled or not) won't get called until inside demuxer::run() (that's a guarantee that asio makes). Since the handler refers to the printer object you will have a problem if the printer is destroyed before the handler gets a chance to run.

Basically you must ensure that any object referred to by a completion handler is alive until the handler is called.

...

I assume your asio library is made up along the reactor pattern isn't it?

No, it's more like proactor (and the win32 implementation uses IO completion ports for most socket operations).

...

What I alsways tried to find out how a reactor is meant to be shutdown. Can you shed some light on this?

The demuxer shuts down (i.e. the demuxer::run function exits) when there is no more work to do. "Work" means unfinished asynchronous operations.

The cleanest way to shut down an app (unfortunately not shown in any of my current examples yet) is to cancel all of your operations. The completion handlers for those operations will be called with an error code result, and once they have all finished the run() will exit.

...

So does the cancel call give me this guarantee? What if another callback is scheduled in midst of cancellation?

As i mentioned above, cancel doesn't cause the callback to be invoked immediately. It just causes the operation to finish early, with an error code.

There is no problem with callbacks running while doing a cancellation, provided you respect thread safety rules (e.g. do not access a timer object from multiple threads simultaneously).

...

I hope you don't mind if I put another few lines:

As many others on the list I am eagerly looking to a network library. And I like asio as I can tell so far.

But I have a basic question that bothers me: Will it be compatible with boost::mutex and boost::conditions? I.e.: Can I wait on networking events _and_ some conditions the same time?

This is perhaps an area that needs more investigation. However, in my and others' experience with asio, once an application is designed to use an asynchronous programming paradigm, it often has no more need for mutexes or condition variables at all!

Instead, everything can be accomplished using a combination of async operations, demuxer::post() and locking_dispatcher to synchronise handlers across threads. This is more like a message passing style of programming.

So basically the asio also needs a change in paradigm? It won't be of much use in the traditional threading sense? Regards, Roland