*Maybe there should be a "run_forever" version of demuxer::run? 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? 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? It looks to me that when they destruct they stop themselves. 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? Not sure avoiding it is worth the trouble. In any case, this probably needs to be documented. *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 automatically. *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. 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.