office-gobmx/binaryurp
Stephan Bergmann d015384e1d Fixed ThreadPool (and dependent ORequestThread) life cycle
At least with sw_complex test under load, it happened that an ORequestThread
could still process a remote release request while the main thread was already
in exit(3).  This was because (a) ThreadPool never joined with the spawned
worker threads (which has been rectified by calling uno_threadpool_dispose(0)
from the final uno_threadpool_destroy), and (b) binaryurp::Bridge called
uno_threadpool_destroy only from its destructor (which could go as late as
exit(3)) instead of from terminate.

Additional clean up:
* Access to Bridge's threadPool_ is now cleanly controlled by mutex_ (even
  though that might not be necessary in every case).
* ThreadPool's stopDisposing got renamed to destroy, to make meaning clearer.

Change-Id: I45fa76e80e790a11065e7bf8ac9d92af2e62f262
2012-05-16 22:09:21 +02:00
..
prj make gbuild the default assumption of build.pl 2012-04-29 03:50:46 +02:00
qa
source Fixed ThreadPool (and dependent ORequestThread) life cycle 2012-05-16 22:09:21 +02:00
CppunitTest_binaryurp_test-cache.mk gbuild: "use" vs. "add": 2012-04-08 01:05:52 +02:00
CppunitTest_binaryurp_test-unmarshal.mk gbuild: "use" vs. "add": 2012-04-08 01:05:52 +02:00
Library_binaryurp.mk gbuild: "use" vs. "add": 2012-04-08 01:05:52 +02:00
Makefile
Module_binaryurp.mk