Re: [boost] another question about asio

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-09-04 09:58:39

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_at_[hidden]> 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