boost::asio::deadline_timer spawns a thread for each timer on Windows

[johnwason]

My application uses lots of deadline_timers to provide timeout functionality for asynchronous operations. It appears that each deadline_timer spawns a thread to manage the wait on Windows. The threads don't complete once I call cancel on the timer. This leads to rapid resource exhaustion. On Windows the best way to implement the timers would be using "CreateTimerQueueTimer". The callback for the timer could then simply post the completion routines to the io_service. Using the flag WT_EXECUTEINTIMERTHREAD could potentially eliminate and performance penalties with the callback although I am not certain if it is legal given the design of asio on Windows. There is some discussion about the accuracy of this function but on windows it is nearly impossible to get timing resolution below ~15 ms using any method so I don't think that should be an issue. I am developing a work-around for my application and can send you the result if you are interested.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682485%28v=vs.85%29.aspx

[chriskohlhoff]

It has an extra thread per io_service. The thread persists so that it can be reused for other timer operations.

What makes you think it is per deadline_timer?

[johnwason]

My test program crashed with an out of resource error and I saw hundreds of threads stuck running the timer management routine in the debugger. My normal thread pool has 20 threads. I only use one io_service.

[chriskohlhoff]

Then can you please supply a small, self-contained test case to reproduce this behaviour. Thanks.

[johnwason]

This is strange, my small test program doesn't reproduce the problem even though it is nearly identical. Here is a screenshot of my threads window to demonstrate that it is a problem:

[chriskohlhoff]

Something must be corrupting the win_iocp_io_service::timer_thread_ member to set it back to NULL, because the logic to launch the thread is this:

void win_iocp_io_service::do_add_timer_queue(timer_queue_base& queue)
{
  mutex::scoped_lock lock(dispatch_mutex_);
  // ...
  if (!timer_thread_.get())
  {
    timer_thread_function thread_function = { this };
    timer_thread_.reset(new thread(thread_function, 65536));
  }
}

Can you try using a data breakpoint to see if it is getting cleared somehow.

[chriskohlhoff]

... and also put a breakpoint on the line:

timer_thread_.reset(new thread(thread_function, 65536));

to find out where it is being called from so many times.

[johnwason]

Ok, it looks like I had a typo that was causing construction of io_service objects. Thanks for the quick response.

[chriskohlhoff]

No problem, glad it's sorted out.