Hopefully this issue hasn't already been discussed -- I apologize if it has -- I've only been able to skim much of the last few days discussion... Another issue discussed by the 'Phoenix Group' (see my IPV4 email for explanation) is the specification of the number of portable timers allowed by asio. As many folks on this list are aware, the number of actual timers that can be set varies by operating system. This fact makes writing portable code that scales to a large number of timers difficult. From our reading of the asio docs there is no statement of limits on the number of timers. One might infer from this that the interface will portably support as many timers as users wish. While this might seem to contradict with OS based limits, it actually doesn't -- ACE and other libraries work around OS limitations by using internal timer queues that minimize (typically to one) the number of actual timers set in the OS. I've had a brief look at the implementation, but it's not clear to me that asio is doing this in all cases. So the questions are: 1) Is the intent to support an 'unlimited' number of timers portably? 2) If yes, does the implementation do this for all platforms? Jeff