The possible issue with the current implementation is that
in theory many possible GC() are being executed in parallel.
In this case just one of them is really working and others
are waiting on the locked mutex (first line of the GC()
method). In such a scenario when a call
to StringTablePrivate::insert() is being executed from one
more thread, it may happen that the working GC() thread
is stopped (since m_stopGCRequested.fetchAndStoreAcquire(true)
was executed from insert()) and later the mutex lock may be
granted to the other awaiting GC() thread instead to the
thread which executes insert() method. In this unlikely
scenario the GC() thread won't be canceled and the lock
inside the insert() method may be locked for considerable
amount of time, what is not desired.
The goal of this patch is to resolve the possible issue above
and to simplify the code by eliminating the m_stopGCRequested
variable and make use of QFuture.cancel() / QFuture.isCanceled()
API instead. In addition, since we control now only one
possible thread that executes the GC(), there is no need for
future synchonizer anymore.
GC() function can't be run in parallel in different threads,
as the whole body of GC() is protected with mutex. This means
that whenever a new scheduled call to GC() is being executed,
this new call waits on the mentioned mutex at the beginning of GC().
So, instead of protecting the whole body of GC() with a mutex,
we ensure that the old call to GC() is already finished (if not,
we also cancel the old call) while preparing an asynchronous
call to start a new GC() from inside startGC() method.
Whenever we are calling the insert() method, we still protect the access
to m_strings with a mutex (as insert() is designed to be called
from different threads in parallel). Just after locking the mutex
we are canceling any possible ongoing call to GC(). After canceling
the GC() call, we are sure that no new call to GC() will be executed
until we unlock the mutex, so it's safe now to modify the m_string
data.
Change-Id: If72d0a6f98fb414c6c63117bc9baa667d17e1ffe
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The issue is that when a GC() function is being executed
in a separate thread, the main thread may delete
the StringTable (on shutdown) in the same time. The destructor of
StringTable didn't check in any way that the other
thread is still executing GC() method.
In order to fix it we employ runAsync method, returning
the handle to the running task. We store the handle
in futureSynchronizer, and in destructor of StringTablePrivate
we safely wait for all futures to be finished.
Fixes: QTCREATORBUG-25417
Change-Id: I0039d6041276c521c221e8dfc3894e84e47b82a2
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
We do it wherever possible. Some places can't be fixed
since they still rely on dynamic introspection
(mainly QQuickItem cases).
Change-Id: Ia00b4a04d8b995c9a43b7bf2dbe76a60364bb8ca
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This does not cover Utils::MapReduceOption with QVector, and code
that's not compiled on my machine.
Change-Id: Ib63923985c52b1bb74e5ec2068a2bb37469ac618
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
warning: prefer using 'override' or (rarely) 'final' instead of
'virtual' [modernize-use-override]
Change-Id: I6dac7a62b627fa1353b4455e1af92f869c2571cc
Reviewed-by: Marco Benelli <marco.benelli@qt.io>
This also fixes a crash on loading (some?) projects introduced
in 577bf7c08a.
Change-Id: Ie35d466fa3b84b183118fe93f55393a4c59755de
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
It is deprecated, and GCC7 warns about RHS expansion to defined.
Change-Id: I161ee9c566ee12d0e443a9054dd0e5cdadc0518e
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
This will hopefully help a bit in resolving the crashes that happen in
QCoreApplication::notifyInternal.
Change-Id: Ib3aa8c1a1f50778bd89938d7c529d8399ccf91ea
Task-number: QTCREATORBUG-11262
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
QStringLiteral() returns a string that has a refcount of -1 and it must
be kept. There is no way to determine if it's still in use, so we'll
just assume it is. Any QStringLiteral inserted into the structure will
stay there forever.
On the other hand, we must not accept unsharable strings, so Q_ASSERT on
that.
Change-Id: I5fbdc1046f0f00319f27fdfb7aa3ff87371ea668
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
This string table uniques strings, so that multiple identical strings
share their contents. It is used by the locator and the symbol searcher,
and will later be used by the class view.
Change-Id: Ib8b50f69bbf994d0d7a39b66dc8caf1a3d9bfb42
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
