2010-10-14 08:30:07 +02:00
|
|
|
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
|
2012-06-13 14:17:57 +01:00
|
|
|
/*
|
|
|
|
* This file is part of the LibreOffice project.
|
|
|
|
*
|
|
|
|
* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
*
|
|
|
|
* This file incorporates work covered by the following license notice:
|
|
|
|
*
|
|
|
|
* Licensed to the Apache Software Foundation (ASF) under one or more
|
|
|
|
* contributor license agreements. See the NOTICE file distributed
|
|
|
|
* with this work for additional information regarding copyright
|
|
|
|
* ownership. The ASF licenses this file to you under the Apache
|
|
|
|
* License, Version 2.0 (the "License"); you may not use this file
|
|
|
|
* except in compliance with the License. You may obtain a copy of
|
|
|
|
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
|
|
|
|
*/
|
2006-09-16 23:19:42 +00:00
|
|
|
|
2014-11-17 11:57:43 +01:00
|
|
|
#include <sal/config.h>
|
|
|
|
|
2015-09-14 09:21:33 +01:00
|
|
|
#include <algorithm>
|
2014-11-17 11:57:43 +01:00
|
|
|
#include <cstdlib>
|
2000-09-18 14:29:57 +00:00
|
|
|
#include <osl/diagnose.h>
|
|
|
|
#include <uno/threadpool.h>
|
2016-03-08 22:22:16 +05:30
|
|
|
#include <sal/log.hxx>
|
2022-05-17 13:57:08 +02:00
|
|
|
#include <utility>
|
2000-09-18 14:29:57 +00:00
|
|
|
|
|
|
|
#include "thread.hxx"
|
|
|
|
#include "jobqueue.hxx"
|
|
|
|
#include "threadpool.hxx"
|
|
|
|
|
2001-02-20 11:43:51 +00:00
|
|
|
using namespace osl;
|
2014-05-19 00:36:42 +02:00
|
|
|
using namespace rtl;
|
2001-02-20 11:43:51 +00:00
|
|
|
|
2000-09-18 14:29:57 +00:00
|
|
|
namespace cppu_threadpool {
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2011-12-19 15:15:28 +01:00
|
|
|
ThreadAdmin::ThreadAdmin(): m_disposed(false) {}
|
|
|
|
|
2001-02-20 11:43:51 +00:00
|
|
|
ThreadAdmin::~ThreadAdmin()
|
|
|
|
{
|
2017-11-17 20:19:56 +01:00
|
|
|
SAL_WARN_IF(m_deque.size(), "cppu.threadpool", m_deque.size() << "Threads left");
|
2001-02-20 11:43:51 +00:00
|
|
|
}
|
|
|
|
|
2021-03-13 18:10:46 +01:00
|
|
|
bool ThreadAdmin::add_locked( rtl::Reference< ORequestThread > const & p )
|
2001-02-20 11:43:51 +00:00
|
|
|
{
|
2011-12-19 15:15:28 +01:00
|
|
|
if( m_disposed )
|
|
|
|
{
|
2014-11-14 16:05:37 +01:00
|
|
|
return false;
|
2011-12-19 15:15:28 +01:00
|
|
|
}
|
2017-11-17 20:19:56 +01:00
|
|
|
m_deque.push_back( p );
|
2014-11-14 16:05:37 +01:00
|
|
|
return true;
|
2001-02-20 11:43:51 +00:00
|
|
|
}
|
|
|
|
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
void ThreadAdmin::remove_locked( rtl::Reference< ORequestThread > const & p )
|
|
|
|
{
|
2017-11-17 20:19:56 +01:00
|
|
|
m_deque.erase(std::find( m_deque.begin(), m_deque.end(), p ), m_deque.end());
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void ThreadAdmin::remove( rtl::Reference< ORequestThread > const & p )
|
2001-02-20 11:43:51 +00:00
|
|
|
{
|
2021-03-13 18:10:46 +01:00
|
|
|
std::scoped_lock aGuard( m_mutex );
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
remove_locked( p );
|
2001-02-20 11:43:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void ThreadAdmin::join()
|
|
|
|
{
|
2011-12-19 15:15:28 +01:00
|
|
|
{
|
2021-03-13 18:10:46 +01:00
|
|
|
std::scoped_lock aGuard( m_mutex );
|
2011-12-19 15:15:28 +01:00
|
|
|
m_disposed = true;
|
|
|
|
}
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
for (;;)
|
2001-02-20 11:43:51 +00:00
|
|
|
{
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
rtl::Reference< ORequestThread > pCurrent;
|
2001-02-20 11:43:51 +00:00
|
|
|
{
|
2021-03-13 18:10:46 +01:00
|
|
|
std::scoped_lock aGuard( m_mutex );
|
2017-11-17 20:19:56 +01:00
|
|
|
if( m_deque.empty() )
|
2001-02-20 11:43:51 +00:00
|
|
|
{
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
break;
|
2001-02-20 11:43:51 +00:00
|
|
|
}
|
2017-11-17 20:19:56 +01:00
|
|
|
pCurrent = m_deque.front();
|
|
|
|
m_deque.pop_front();
|
2001-02-20 11:43:51 +00:00
|
|
|
}
|
Prevent self-join in ThreadAdmin::join
Depending on timing, it can apparently happen at least during
JunitTest_unordf_complex that a cppu_threadpool::ORequestThread having executed
a binaryurp::IncomingRequest holds the last binaryurp::Bridge reference:
> #2 0x00007fac4ad6bf97 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7fac4b4e8c22 "false", file=file@entry=0x7fac4b4eaec7 "sal/osl/unx/thread.cxx", line=line@entry=443, function=function@entry=0x7fac4b4eaefd "void osl_joinWithThread(oslThread)") at assert.c:92
> #3 0x00007fac4ad6c042 in __GI___assert_fail (assertion=0x7fac4b4e8c22 "false", file=0x7fac4b4eaec7 "sal/osl/unx/thread.cxx", line=443, function=0x7fac4b4eaefd "void osl_joinWithThread(oslThread)") at assert.c:101
> #4 0x00007fac4b4d5258 in osl_joinWithThread(oslThread) (Thread=0x7fabfc0011d0) at sal/osl/unx/thread.cxx:443
> #5 0x00007fac47fbdde5 in cppu_threadpool::ThreadAdmin::join() (this=0x7fac1c0069e0) at cppu/source/threadpool/thread.cxx:89
> #6 0x00007fac47fc23af in cppu_threadpool::ThreadPool::joinWorkers() (this=<optimized out>) at cppu/source/threadpool/threadpool.cxx:179
> #7 0x00007fac47fc35b7 in uno_threadpool_destroy(uno_ThreadPool) (hPool=<optimized out>) at cppu/source/threadpool/threadpool.cxx:499
> #8 0x00007fac25b03b5c in binaryurp::Bridge::terminate(bool) (this=0x7fac24117078, final=true) at binaryurp/source/bridge.cxx:277
> #9 0x00007fac25b0794e in binaryurp::Bridge::dispose() (this=0x7fac24117078) at binaryurp/source/bridge.cxx:904
> #10 0x00007fac25b07215 in binaryurp::Bridge::~Bridge() (this=0x7fac24117078) at binaryurp/source/bridge.cxx:847
> #11 0x00007fac25b07409 in binaryurp::Bridge::~Bridge() (this=0x7fac24117078) at binaryurp/source/bridge.cxx:838
> #12 0x00007fac25b39ee1 in std::default_delete<binaryurp::IncomingRequest>::operator()(binaryurp::IncomingRequest*) const (this=<optimized out>, __ptr=0x7fabfc00ba50) at /usr/lib/gcc/x86_64-redhat-linux/6.2.1/../../../../include/c++/6.2.1/bits/unique_ptr.h:76
> #13 0x00007fac25b38fa8 in std::unique_ptr<binaryurp::IncomingRequest, std::default_delete<binaryurp::IncomingRequest> >::~unique_ptr() (this=0x7fac0bb74ac0) at /usr/lib/gcc/x86_64-redhat-linux/6.2.1/../../../../include/c++/6.2.1/bits/unique_ptr.h:236
> #14 0x00007fac25b36d71 in request(void*) (pThreadSpecificData=<optimized out>) at binaryurp/source/reader.cxx:83
> #15 0x00007fac47fbaa95 in cppu_threadpool::JobQueue::enter(long, bool) (this=<optimized out>, nDisposeId=<optimized out>, bReturnWhenNoJob=<optimized out>) at cppu/source/threadpool/jobqueue.cxx:107
> #16 0x00007fac47fbe1f9 in cppu_threadpool::ORequestThread::run() (this=0x7fabfc001160) at cppu/source/threadpool/thread.cxx:165
> #17 0x00007fac47fbf9ca in threadFunc(void*) (param=0x7fabfc001170) at include/osl/thread.hxx:185
> #18 0x00007fac4b4d5a3c in osl_thread_start_Impl(void*) (pData=0x7fabfc0011d0) at sal/osl/unx/thread.cxx:240
> #19 0x00007fac4ab2a5ca in start_thread (arg=0x7fac0bb75700) at pthread_create.c:333
> #20 0x00007fac4ae420ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
while the main thread is already shutting down:
> #19 0x00007fac4b14100f in desktop::Desktop::doShutdown() (this=0x7fff8a6149d0) at desktop/source/app/app.cxx:1783
> #20 0x00007fac4b13f505 in desktop::Desktop::Main() (this=0x7fff8a6149d0) at desktop/source/app/app.cxx:1716
> #21 0x00007fac419a0f79 in ImplSVMain() () at vcl/source/app/svmain.cxx:185
> #22 0x00007fac419a1c14 in SVMain() () at vcl/source/app/svmain.cxx:223
> #23 0x00007fac4b17c773 in soffice_main() () at desktop/source/app/sofficemain.cxx:166
> #24 0x0000000000400916 in sal_main () at desktop/source/app/main.c:48
> #25 0x00000000004008fb in main (argc=<optimized out>, argv=<optimized out>) at desktop/source/app/main.c:47
Change-Id: I34beac40e89f6d522af49f9dcdb3ed2fc1259c4b
2016-12-07 12:33:17 +01:00
|
|
|
if (pCurrent->getIdentifier()
|
|
|
|
!= osl::Thread::getCurrentIdentifier())
|
|
|
|
{
|
|
|
|
pCurrent->join();
|
|
|
|
}
|
2001-02-20 11:43:51 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2022-05-17 13:57:08 +02:00
|
|
|
ORequestThread::ORequestThread( ThreadPoolHolder aThreadPool,
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
JobQueue *pQueue,
|
2022-05-17 13:57:08 +02:00
|
|
|
ByteSequence aThreadId,
|
2014-02-15 17:39:35 +01:00
|
|
|
bool bAsynchron )
|
2022-05-17 13:57:08 +02:00
|
|
|
: m_aThreadPool(std::move( aThreadPool ))
|
2004-04-21 11:57:06 +00:00
|
|
|
, m_pQueue( pQueue )
|
2022-05-17 13:57:08 +02:00
|
|
|
, m_aThreadId(std::move( aThreadId ))
|
2000-09-18 14:29:57 +00:00
|
|
|
, m_bAsynchron( bAsynchron )
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
{}
|
2000-09-18 14:29:57 +00:00
|
|
|
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
ORequestThread::~ORequestThread() {}
|
2000-09-18 14:29:57 +00:00
|
|
|
|
|
|
|
void ORequestThread::setTask( JobQueue *pQueue,
|
|
|
|
const ByteSequence &aThreadId,
|
2014-02-15 17:39:35 +01:00
|
|
|
bool bAsynchron )
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
|
|
|
m_pQueue = pQueue;
|
|
|
|
m_aThreadId = aThreadId;
|
|
|
|
m_bAsynchron = bAsynchron;
|
|
|
|
}
|
|
|
|
|
2014-11-14 16:05:37 +01:00
|
|
|
bool ORequestThread::launch()
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
// Assumption is that osl::Thread::create returns normally with a true
|
2017-05-18 21:58:31 +02:00
|
|
|
// return value iff it causes osl::Thread::run to start executing:
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
acquire();
|
|
|
|
ThreadAdmin & rThreadAdmin = m_aThreadPool->getThreadAdmin();
|
2021-03-13 18:10:46 +01:00
|
|
|
std::unique_lock g(rThreadAdmin.m_mutex);
|
|
|
|
if (!rThreadAdmin.add_locked( this )) {
|
2014-11-14 16:05:37 +01:00
|
|
|
return false;
|
|
|
|
}
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
try {
|
|
|
|
if (!create()) {
|
2014-11-17 11:57:43 +01:00
|
|
|
std::abort();
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
}
|
|
|
|
} catch (...) {
|
|
|
|
rThreadAdmin.remove_locked( this );
|
2021-03-13 18:10:46 +01:00
|
|
|
g.release();
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
release();
|
|
|
|
throw;
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
2014-11-14 16:05:37 +01:00
|
|
|
return true;
|
2001-02-20 11:43:51 +00:00
|
|
|
}
|
|
|
|
|
2000-09-18 14:29:57 +00:00
|
|
|
void ORequestThread::onTerminated()
|
|
|
|
{
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
m_aThreadPool->getThreadAdmin().remove( this );
|
|
|
|
release();
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void ORequestThread::run()
|
|
|
|
{
|
2014-08-22 23:51:08 +02:00
|
|
|
osl_setThreadName("cppu_threadpool::ORequestThread");
|
|
|
|
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
try
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
while ( m_pQueue )
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
if( ! m_bAsynchron )
|
2006-06-19 12:12:31 +00:00
|
|
|
{
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
if ( !uno_bindIdToCurrentThread( m_aThreadId.getHandle() ) )
|
|
|
|
{
|
2017-05-07 17:03:35 +10:00
|
|
|
OSL_ASSERT( false );
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
}
|
2006-06-19 12:12:31 +00:00
|
|
|
}
|
2000-09-18 14:29:57 +00:00
|
|
|
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
while( ! m_pQueue->isEmpty() )
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
// Note : Oneways should not get a disposable disposeid,
|
|
|
|
// It does not make sense to dispose a call in this state.
|
2019-04-10 16:04:56 +00:00
|
|
|
// That's way we put it a disposeid, that can't be used otherwise.
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
m_pQueue->enter(
|
2020-06-15 19:41:37 +02:00
|
|
|
this,
|
2014-02-15 17:39:35 +01:00
|
|
|
true );
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
|
|
|
|
if( m_pQueue->isEmpty() )
|
|
|
|
{
|
|
|
|
m_aThreadPool->revokeQueue( m_aThreadId , m_bAsynchron );
|
|
|
|
// Note : revokeQueue might have failed because m_pQueue.isEmpty()
|
|
|
|
// may be false (race).
|
|
|
|
}
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
delete m_pQueue;
|
2015-11-10 10:12:56 +01:00
|
|
|
m_pQueue = nullptr;
|
2000-09-18 14:29:57 +00:00
|
|
|
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
if( ! m_bAsynchron )
|
|
|
|
{
|
|
|
|
uno_releaseIdFromCurrentThread();
|
|
|
|
}
|
2000-09-18 14:29:57 +00:00
|
|
|
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "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 09:42:37 +02:00
|
|
|
m_aThreadPool->waitInPool( this );
|
|
|
|
}
|
|
|
|
}
|
|
|
|
catch (...)
|
|
|
|
{
|
|
|
|
// Work around the problem that onTerminated is not called if run
|
|
|
|
// throws an exception:
|
|
|
|
onTerminated();
|
|
|
|
throw;
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2010-10-14 08:30:07 +02:00
|
|
|
|
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|