TimerManager::add() bug when new timeout < current timeout
----------------------------------------------------------
Key: THRIFT-469
URL: https://issues.apache.org/jira/browse/THRIFT-469
Project: Thrift
Issue Type: Bug
Components: Library (C++)
Affects Versions: 0.1
Environment: Mac OS X 10.5.6
Reporter: Rush Manbert
The function:
void TimerManager::add(shared_ptr<Runnable> task, int64_t timeout)
inserts the new task into the taskMap_, then executes this code:
if (taskCount_ == 1 || timeout < taskMap_.begin()->first) {
monitor_.notify();
}
which doesn't call monitor_.notify() when the new task's timeout is < the
current timeout, because the timeout portion of the test ends up testing
timeout against itself.
The TimerManagerTests::test00 doesn't reveal this problem when concurrency_test
is built as part of the normal make. That's because there is a race between the
TimerManager dispatcher starting and the test inserting the two test tasks. If
the test delays for 1 second after adding orphanTask, then the test fails every
time, because the dispatcher never gets broken out of the 10 second sleep he
starts when orphanTask was inserted. I saw the error because I built a debug
version of concurrency_test, which changed the timing enough to reveal the bug.
I will attach patches for both the test and TimerManager.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
