.

.

.

ok in sb49

See issue 63473 for details.

changes made:
 bridges/source/remote/context/context.cxx:1.6.20.1
 cppu/prj/build.lst:1.10.40.1
 cppu/source/threadpool/jobqueue.cxx:1.3.38.1
 cppu/source/threadpool/jobqueue.hxx:1.3.38.1
 cppu/source/threadpool/thread.cxx:1.7.38.1
 cppu/source/threadpool/thread.hxx:1.4.40.1
 cppu/source/threadpool/threadpool.cxx:1.12.38.1
 cppu/source/threadpool/threadpool.hxx:1.2.38.1
 cppu/source/uno/lbmap.cxx:1.23.38.1
 cppu/util/makefile.mk:1.7.40.1

reopen

back to sb

JSC -> SB: Stephan i reopened the bug because i moved your changes back because
of a UNO remote problem (second connect failed, C++ and Java and probaly other
languges as well). Internal P1 issue 134738 -> automatic testtool doesn't work

i have changed back:
cppu/source/threadpool/jobqueue.cxx:1.4 to1.3
cppu/source/threadpool/jobqueue.hxx:1.4 to 1.3
cppu/source/threadpool/thread.cxx:1.8 to 1.7
cppu/source/threadpool/thread.hxx:1.5 to 1.4
cppu/source/threadpool/threadpool.cxx:1.13 to 1.12
cppu/source/threadpool/threadpool.hxx:1.3 to 1.2

=> 2.0.4

.

cppu/source/threadpool/threadpool.cxx:1.13 fails to take into account that
uno_threadpool_destroy might be followed by uno_threadpool_create again (if one
remote connection is used and terminated, and then another remote connection is
used).  A simple g_threadPool=0 at the end of uno_threadpool_destroy is not
enough, however:  For one, g_threadPool must be set to zero only if its refcount
reaches zero, and for another, uno_threadpool_attach/detach probably also need
to adjust g_threadPool's refcount to synchronize with another thread calling
uno_threadpool_destroy.

target 2.x

Issue 80121 is probably a duplicate of this issue.  Remember to undo that
issue's "temporary fix [...] to dispose the bridges directly."

see also issue 111223

The changes made to bridges/source/remote/context/context.cxx:1.6.20.1 have
effectively been reverted through issue 112784.

Confusing comments but it seems this issue was either resolved or a duplicate of another.