office-gobmx

History

Stephan Bergmann 2fa2660b55 Better fix for ThreadPool/ORequestThread life cycle This is a follow up to `d015384e1d` "Fixed ThreadPool (and dependent ORequestThread) life cycle" that still had some problems: * First, if Bridge::terminate was first entered from the reader or writer thread, it would not join on that thread, so that thread could still be running during exit. That has been addressed by giving Bridge::dispose new semantics: It waits until both Bridge::terminate has completed (even if that was called from a different thread) and all spawned threads (reader, writer, ORequestThread workers) have been joined. (This implies that Bridge::dispose must not be called from such a thread, to avoid deadlock.) * Second, if Bridge::terminate was first entered from an ORequestThread, the call to uno_threadpool_dispose(0) to join on all such worker threads could deadlock. That has been addressed by making the last call to uno_threadpool_destroy wait to join on all worker threads, and by calling uno_threadpool_destroy only from the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The special semantics of uno_threadpool_dispose(0) are no longer needed and have been removed, as they conflicted with the fix for the third problem below.) * Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the ThreadAdmin singleton had been disposed, so no new remote bridges could successfully be created afterwards. That has been addressed by making ThreadAdmin a member of ThreadPool, and making (only) those uno_ThreadPool handles with overlapping life spans share one ThreadPool instance (which thus is no longer a singleton, either). Additionally, ORequestThread has been made more robust (in the style of salhelper::Thread) to avoid races. Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f		2012-05-23 10:10:51 +02:00
..
inc	Better fix for ThreadPool/ORequestThread life cycle	2012-05-23 10:10:51 +02:00
prj	make gbuild the default assumption of build.pl	2012-04-29 03:50:46 +02:00
qa	cppu: use InternalUnoApi	2012-04-09 21:04:37 +02:00
source	Better fix for ThreadPool/ORequestThread life cycle	2012-05-23 10:10:51 +02:00
util	fdo#42865: privatized unique empty string symbol:	2012-05-18 16:33:19 +02:00
CppunitTest_cppu_qa_any.mk	cppu: use InternalUnoApi	2012-04-09 21:04:37 +02:00
CppunitTest_cppu_qa_recursion.mk	cppu: use InternalUnoApi	2012-04-09 21:04:37 +02:00
CppunitTest_cppu_qa_reference.mk	cppu: use InternalUnoApi	2012-04-09 21:04:37 +02:00
CppunitTest_cppu_qa_unotype.mk	cppu: use InternalUnoApi	2012-04-09 21:04:37 +02:00
CppunitTest_cppu_test_cppumaker.mk	cppu: use InternalUnoApi	2012-04-09 21:04:37 +02:00
InternalUnoApi_cppu.mk	cppu: use InternalUnoApi	2012-04-09 21:04:37 +02:00
Library_affine_uno.mk	cppu: use InternalUnoApi	2012-04-09 21:04:37 +02:00
Library_cppu.mk	Better fix for ThreadPool/ORequestThread life cycle	2012-05-23 10:10:51 +02:00
Library_log_uno.mk	cppu: use InternalUnoApi	2012-04-09 21:04:37 +02:00
Library_purpenvhelper.mk	cppu: use InternalUnoApi	2012-04-09 21:04:37 +02:00
Library_unsafe_uno.mk	cppu: use InternalUnoApi	2012-04-09 21:04:37 +02:00
Makefile
Module_cppu.mk	cppu: use InternalUnoApi	2012-04-09 21:04:37 +02:00
Package_inc.mk
README

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]