This improves on b68640c44e "Prevent creation of
new ORequestThreads during shutdown," which added throwing the DisposedException
from ThreadAdmin::add. But ThreadAdmin::m_disposed can only become true via
uno_threadpool_destroy -> ThreadPool::joinWorkers -> ThreadAdmin::join, and
ThreadAdmin::add observing that can only happen via uno_threadpool_putJob ->
ThreadPool::addJob -> ThreadPool::createThread -> ORequestThread::launch ->
ThradAdmin::add, where the bridges should ensure that uno_threadpool_destroy
does not run in parallel with uno_threadpool_putJob. So demote this from a
DisposedException to a SAL_WARN.
Change-Id: I3912ea077b7fa35827c41e82dd0a8f962ba412b6
Add a macro in include/cppuhelper/implbase_ex.hxx
to make initialising the type_entry classes a little less verbose.
Change-Id: I0904b5b9db269c92bc89e7ce3d6c8b09350c9897
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
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
SAL_UNUSED_PARAMETER (expanding to __attribute__ ((unused)) for GCC)
is used to annotate legitimately unused parameters, so that static
analysis tools can tell legitimately unused parameters from truly
unnecessary ones. To that end, some patches for external modules
are also added, that are only applied when compiling with GCC and
add necessary __attribute__ ((unused)) in headers.
2007/06/07 10:54:33 kr 1.16.36.2: fixed: #i77600# warning because of wrong format specifier - now uses C++ style casts
2007/06/07 09:22:29 kr 1.16.36.1: fixed: #i77600# warning because of wrong format specifier
2006/03/22 10:14:06 sb 1.12.38.1: #i63397# Keep objects alive long enough so that threads still running while atexit handlers are processed do not access dead objects.
