Thank you so much. It makes sense from what I've observed. Three final questions on this: 1) Let's say I've posted a request for a function, called handleClose, onto the handler Queue from a function called close() which can be called from a thread different from the IO service thread. The handleClose function will call the cancel on the socket. Would it be possible while I'm inside this handler, for ASIO to post more requests onto the queue. E.g. let's say I've just entered my handleClose handler. Before issuing the cancel, is it possible that ASIO could schedule a handleRead for a successful read of a packet, or is the asynchronous socket operations blocked by the fact that I'm inside a handler, meaning that I can assume that if I'm inside my handleClose function, I won't get any handlers posted by ASIO in the mean time, and thus the only handleRead and handleWrite, etc. that I'll get will be ones with a cancelled/aborted error (i.e. not success as error code when the handleRead is called after my handleClose has executed) due to the cancel called inside handleClose? 2) Does the above logic apply to timers also? In other words, I won't get a handleTimer function posted with a success as error code for a deadline timer while I'm inside the handleClose function? I'll need to cancel the timer inside my handleClose function, but I'm afraid that I'll get a handleTimer with a success instead of cancelled/aborted after my handleClose function is done, if, while I'm inside my handleClose function, just before the timer is cancelled, the timer expires, meaning that even though I've cancelled the timer, I'll still get the handleTimer called with success as error code indicating that the timer has expired? 3) Are the events for the handlers placed on the queue always in sequence. In other words, if I cancel a read operation and then post a function handleDestroy, then I'll always get handleRead with aborted/cancelled called before I get a handleDestroy called? In this case the cancel interrupts the async read, which will post a handleRead at the point of the cancel being called and not after the handleClose function exits, which means that handleRead will occur before the handleDestroy? Many thanks for the advice! Kind regards, Derik On Thu, 2009-08-06 at 18:16 +0300, Igor R wrote:
In ASIO, when I execute a cancel() on a tcp::socket, does it remove all of the handlers associated with the socket from the handler queue?
No. Every async_XXX request must end with its handler invocation.
<...>
Let's assume now that the object destructs before the handleRead is called
This is very bad and will cause crash/segfault. Parts of your handler (incl. the bound object) must not cease before the async.operation is complete.
Also, as reading and writing operations are done in the IO service thread, would it be safe to call the tcp::socket cancel from another thread (e.g. in the destructor of a class)?
No. You should post() the cancel operation to io_service thread. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users