diff options
author | Christian Mollekopf <chrigi_1@fastmail.fm> | 2018-08-06 13:33:53 +0200 |
---|---|---|
committer | Christian Mollekopf <chrigi_1@fastmail.fm> | 2018-08-06 13:33:53 +0200 |
commit | f2fac63e086b4bd8dfc3ed9c9f31241eb9df9b9c (patch) | |
tree | eeaa0c8a560bf9c0b9814347353465f5dad36cd5 /common/resultset.h | |
parent | b4341b9ba3f0242ff95fb229a80b4143c1369c34 (diff) | |
download | sink-f2fac63e086b4bd8dfc3ed9c9f31241eb9df9b9c.tar.gz sink-f2fac63e086b4bd8dfc3ed9c9f31241eb9df9b9c.zip |
Fixed threading issues with dynamic db creation.
This patch addresses two problems:
* A potential deadlock.
We had the following code inside a separately protected section:
dbiLocker.unlock();
//Here we could loos the readlock
QWriteLocker dbiWriteLocker(&sDbisLock);
If we lost the lock in between the two lines, the second thread that was
now holding a read-lock on sDbisLock could not enter the protected
section, which was a requirement to release the read-lock, and we'd thus
end up in a deadlock. This is solved using tryLock with intermediate
releases of the read-lock, allowing the original thread to finish.
* When failing to validate a dbi for the current transacation we
simply returned an invalid db (which then in this particular case broke
reading of revision uid's and type's), leading to queries not executing
as they should.
Both problems are unfortunately hard to reproduce, the adjusted test
at leaset allowed me to reproduce the deadlock situation sometimes.
To fix this cleanly we should probably just get rid of dynamic dbi
allocation for good.
Diffstat (limited to 'common/resultset.h')
0 files changed, 0 insertions, 0 deletions