Boost logo

Boost Users :

Subject: [Boost-users] boost asio: boost::asio::deadline_timer blocking ?
From: Avi Bahra (avibahra_at_[hidden])
Date: 2012-11-09 05:40:48


Using boost asio 1.47, suse linux 11.3, gcc 4.5

I am using boost::asio::deadline_timer, where the timer fires every second.
When the timer expires, I check responses from the clients.
I use the same timer to check when I have reach the minute boundary,
so that server can do some other work.

Now 99.9% of the time this works perfectly. However occasionally
the timer does not fire every second, in fact it can delay/block for
several minutes!

This is what I use:

   timer_.expires_from_now( boost::posix_time::seconds( 1 ) );
   timer_.async_wait( server_->io_service_.wrap( boost::bind(
&NodeTreeTraverser::traverse,this,boost::asio::placeholders::error ) )
);

When I run strace on the process I see:

epoll_wait(4, {{EPOLLIN, {u32=15957244, u64=15957244}}}, 128, 4294967295) = 1
timerfd_settime(5, 0, {it_interval={0, 0}, it_value={16, 944525000}},
{it_interval={16048400, 15957984}, it_value={140733847085872,
6025966}}) = 0
timerfd_settime(5, 0, {it_interval={0, 0}, it_value={0, 999992000}},
{it_interval={15958092, 6011901}, it_value={17195917584,
140733847086024}}) = 0

I have several questions:

  o Are there known problems with boost::asio::deadline_timer accuracy
     I realise I need soft real time, with one minute resolution.
  o Should I have two separate timers, one 1 second & for 1 minute
  o Is using timer_.expires_at(...) more reliable, I assume this affects
     how it configures timerfd_settime
  o Now I suspect this issue may be related to slow disk system
     Could a slow disk system affect timerfd_settime system call,
     since it is based on file descriptors.
  o Are there any well known asio based design patterns/idioms
    for ensuring reliable timer resolutions

  Any help appreciated.

Ta,
    Avi


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net