Hi Simon, --- simon meiklejohn <simon@simonmeiklejohn.com> wrote:
1. is this in the pipeline for review in boost?
Not yet, but should be real soon now.
2. Given the contentious nature of I/O discussions in boost would it be possible to unbundle the threading aspect of your lib and get that part into boost sooner? <grin>
Hopefully it won't come to that :)
3. what's your approach to objects mentioned in the callback handler being deleted before the callback is made? Is it the responsibility of the Handler to manage this? Any wrappers for this functionality (e.g. using weak_ptr)
It is the responsibility of the initiator of the post(), dispatch() or asynchronous operation to ensure that anything referenced by the handler is still alive when the handler is invoked. One way of achieving this is to use shared_ptr data members in the handler. E.g. in the http/server example where the connection object passes shared_from_this() to all asynchronous operations. Another thing is that the library ensures that the handler is invoked exactly once (except in case of demuxer::run() being interrupt()ed and not resumed). So an alternative approach might be to clean up the objects when the handler itself is invoked.
4. Is a Win32 GUI thread based asio::demuxer available?
No.
Couldn't quite get my head around getting windows events into such a thing.
Yeah, sounds like it could be tricky to implement. It might be easier to just implement the Dispatcher concept for windows events and call demuxer::run() in a background thread. Then to have completion handlers called in the windows-event-handling thread you would do something like: my_socket.async_receive(buffers, my_windows_event_dispatcher.wrap(my_handler)); where the wrap() function causes the handler invocation to be forwarded to the windows-event-based dispatcher. Cheers, Chris