Re: [boost] boost::defer - generalised execution deferral

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-11-26 06:11:57

Hi Simon,

--- simon meiklejohn <simon_at_[hidden]> 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