d015384e1d
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 |
||
|---|---|---|
| .. | ||
| inc | ||
| prj | ||
| qa | ||
| source | ||
| util | ||
| CppunitTest_cppu_qa_any.mk | ||
| CppunitTest_cppu_qa_recursion.mk | ||
| CppunitTest_cppu_qa_reference.mk | ||
| CppunitTest_cppu_qa_unotype.mk | ||
| CppunitTest_cppu_test_cppumaker.mk | ||
| InternalUnoApi_cppu.mk | ||
| Library_affine_uno.mk | ||
| Library_cppu.mk | ||
| Library_log_uno.mk | ||
| Library_purpenvhelper.mk | ||
| Library_unsafe_uno.mk | ||
| Makefile | ||
| Module_cppu.mk | ||
| Package_inc.mk | ||
| README | ||
Type definitions/implementations for the core of UNO. The exported API is in C. See also: [http://wiki.services.openoffice.org/wiki/Uno/Binary/Modules/CPPU]