From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-28 07:08:10
--- Andrew Schweitzer <a.schweitzer.grps_at_[hidden]> wrote:
> *Maybe there should be a "run_forever" version of demuxer::run?
If you want it to run forever just give it some "work":
In general you'll want to destroy the work object when you
actually do want the demuxer to exit.
> If I read the docs correctly, demuxer::run will exit if it has
> nothing left to do. So if the last timer expires, run will
> exit. The next time a timer is started demuxer::reset and
> demuxer::run must be called again or nothing will happen. Is
> this correct?
Yes. However, an application that is written to use an
asynchronous approach will continue to start asynchronous
operations (e.g. a server will always have an async_accept
> Could this happen for sockets as well, if user never called a
> function like read or accept that will sit there forever until
> something happens? For example, if a client problem calls run,
> does an async connect, sends some data, but doesn't do a read,
> then would run stop after the send completed?
> Or would run wait for socket to be closed?
> *It looks like deadline_timer objects need to be dynamically
> allocated, right?
No, the deadline_timer object itself does not need to be
> It looks to me that when they destruct they stop themselves.
The destructor implicitly cancels any outstanding asynchronous
wait, yes. The handler for that wait operation is still
> I think this means that there are two dynamic allocations per
> timer started, one for the implementation and one for the
> "handle". Could this be avoided?
Yes, looking at the implementation again I can probably change
it to eliminate the dynamic memory allocation of the handler as
> *Since user must allocate each deadline_timer (assuming above
> correct), then user must remember to toss them when timer
> completes. It might be nice if this could be handled
Since you don't have to dynamically allocate the deadline_timer
object this doesn't apply :)
> *There aren't really unique IDs for timers, right? The address
> of the timer object must be unique as long as the timer is
> running, but after the timer completes it could be re-used for
> another timer, so that doesn't seem like a great idea.
This address is used internally as a cancellation token. Since
the destruction of a deadline_timer automatically cancels the
timer (and removes the token from the backend), it's not a
problem if the address gets reused.
> Does anyone else think unique timer IDs belong in the library?
> I'm not sure it's requirement, but most timer code I've worked
> on has used a unique ID. It's not hard for the application to
> provide this, but it is a bit more work.
What use case are you thinking of here? I have never had a need
for a timer ID when instead I can use boost::bind to associate
whatever data I need directly with the completion handler.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk