[vbox-dev] Fix to #13802

[Klaus Espenlaub]

Hi Alexander,

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 
rewrite.

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.

Klaus

On 30.01.2015 15:56, a.urakov at drweb.com wrote:
> Hello!
>
> 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).
>
> Regards,
> Alexander