[Ace-users] [ace-bugs] [ACE_Message_Queue] notify PIPE block causesSelect_Reactor deadlock.
Douglas C. Schmidt
schmidt at dre.vanderbilt.edu
Wed Feb 27 16:17:22 CST 2008
> Thanks for the answer, and thanks for the great work with ACE!
You are very welcome!
> I agree that having a non-regression test case for the deadlock
> problem is useful. If there had been one, the 2003 fix restoring the
> deadlock problem would probably not have happened.
> However, having a test case for the deadlock issue would not help you
> create a fix avoiding the race conditions. If it was me, I'd do the
> "obvious" fix for the deadlock (after running all the available tests)
> and deal with the race conditions correctly if and when when they
The problem, of course, is that race conditions are hard to detect, so a
program may appear to work during simpe smoke testing, when in fact it
has a bug that appears in production. In contrast, the deadlock
situation manifests itself fairly easily, so it can be detected and
addressed, e.g., by designing the program to avoid a deadlock.
> Otherwise, we put ourselves in a deadlock. We are willing to fix this
> only if we can make sure we don't create race conditions, but we are
> not able to verify this because we don't have a test case for those
> race conditions.
Right, but hopefully you can understand why we don't want to apply a fix
that is known to cause problems since it will break a lot of production
code in subtle and pernicious ways.
> IMHO, the immediate problem is that we don't have a test case for
> reproducing the "race conditions"
How about we do the following:
1. Add a regression test for the current deadlock case.
2. Add suggested fixes for the current problem to bugzilla so they don't
3. Try to create a regression test that demonstrates the race
4. If we get #3 then we can enhance the solutions for #2 to avoid both
problems #1 and #3.
In the meantime, you can patch your code locally to avoid the deadlock -
such is the power of open-source ;-)
More information about the Ace-users