[REVIEW-3-5] Better fix for ThreadPool/ORequestThread life cycle

[Stephan Bergmann]

On 05/19/2012 09:57 PM, Caolán McNamara wrote:
> On Fri, 2012-05-18 at 23:04 +0200, Stephan Bergmann wrote:
>> I'd like to get this reviewed and backported to libreoffice-3-5.  As
>> the commit message explains, only part of it is strictly necessary to
>> fix the bug, so
>
> fair enough, won't pretend to understand area fully, but pushed anyway.
> I do recall there was some semi-reproducible crash/hang scenario in the
> past which could be replicated by effectively
> for (i = 0; i<  10000; ++i) unopkg add XXX, unopkg remove XXX;

...yeah, now that you mentioned that, I remembered how fine a test case 
that was.  Only to find out that this "fix" was fundamentally 
flawed---see commit message of 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=2fa2660b55a34a5780f9ea8dbbbe92d05dc9a818> 
"Better fix for ThreadPool/ORequestThread life cycle" for details.

With this second fix, however, calling unopkg add/remove of active.oxt 
and passive.oxt (from desktop/test/deployment/) in a tight loop revealed 
no anomalies any longer, on neither master nor libreoffice-3-5 (and on 
master, I let it burn cycles all night long; the only problem it 
revealed was sporadic crashes from within pyuno::GCThread::execute while 
main thread is already exiting---a known problem, to be addressed 
separately, eventually).

So, please somebody review this additional fix and backport it to 
libreoffice-3-5.  As the master commit would not cleanly apply to 
libreoffice-3-5, I attached an adapted 
0001-Better-fix-for-ThreadPool-ORequestThread-life-cycle.patch.

Thanks,
Stephan