[vbox-dev] Fix to #13802
klaus.espenlaub at oracle.com
Wed Feb 11 17:04:39 UTC 2015
this patch (after having to spend a LOT of time on analyzing the warped
logic of the code) fixes a genuine issue. I haven't made up my mind if
it's the best solution.
The entire XPCOM code is rather convoluted, and an alternative solution
would be that the thread which distributes work to the workers should be
responsible for decreasing the free worker count *before* kicking the
free workers. It doesn't matter which worker actually gets woken up.
Unfortunately that's rather difficult to implement without a complete
Ultimately the true issue is the convoluted, hard to maintain code
(maximizing the non-deterministic behavior and thus the mental effort to
understand a small part of how the code works - the reason why this very
evil and very rare bug survived).
Redoing the code to be easier to understand is a huge effort, which
makes me lean towards your solution.
On 30.01.2015 15:56, a.urakov at drweb.com wrote:
> We would like to contribute to VirtualBox under MIT license. We send our
> changes to fix bug described at https://www.virtualbox.org/ticket/13802 .
> The idea is that we not only check waiting workers presence but also
> compare amount of waiting workers and amount of requests. So when amount
> of request is greater than amount of free workers (and situation not
> changed after short sleeping) we create new worker. In this case there
> will be always sufficient amount of workers.
> We find amount of requests by iterating through whole list and it seems
> like it doesn't cause execution speed decreasing (due to not so big
> requests queue). But if there will be some problems with it we can
> correct code to count elements on every appending / removing operation
> (this way not so good because count variable must be changed in every
> append / remove / etc operation and every new operation in ipcList class).
More information about the vbox-dev