[omniORB] onmiAsyncWorker bug fix proposal

Duncan Grisby duncan at grisby.org
Fri Jul 22 13:26:24 BST 2005


On Thursday 21 July, Raschick wrote:

[...]
> If this happens, the worker is _not_ de-Q'd and tries again to fetch a
> task. If that again fails, because the are no immediate tasks to
> process it will try to linger again, a second time inserting itself
> into the idle thread list. If now two tasks occur they will fetch the
> same worker. "One" worker could even already be deleted when the
> second tries to start (or runs). The "least" that could happen is
> there'd be a double free. One of those is what happened in our case,
> we believe.

Thanks for the bug report and proposed fix. I have checked in a fix to
cvs. It's not actually necessary to use your fix with a flag -- my fix
just looks at the pd_next member to know whether the worker is in the
idle queue or not.

[...]
>        // Dequeue by omniAsyncInvoker. // isn't that the comment for
> the break above?!
>        continue;

To answer your question, the comment really does apply to the continue,
it's just a very cryptic comment. What it means is that if the condition
variable has been signalled, which is the expectation when reaching the
continue (unless the bug you've found occurs), then the omniAsyncInvoker
has removed the worker from the idle queue, and the next time around the
loop will handle the task. I've modified the comment to make more sense.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --



More information about the omniORB-list mailing list