diff options
author | Marc Mutz <marc.mutz@kdab.com> | 2019-07-04 16:59:32 +0200 |
---|---|---|
committer | Marc Mutz <marc.mutz@kdab.com> | 2019-07-18 11:38:02 +0000 |
commit | eaceabe9ac0dbc659ba4683a0dd66effcec461f6 (patch) | |
tree | 93c12d7c195f3938c1a392b6b3a99456b1b8cfe7 /src/network/kernel/qnetworkinterface.h | |
parent | d35aedc1253ec99997f99e422a66c29e51e331b1 (diff) |
QHostInfo: port from recursive to non-recursive mutex
It turns out that the only reason a recursive mutex is used was
because work() was locking it. But work() was only ever called from
functions that already had locked the mutex themselves, and kept it
locked across the call to work(). Clearly mark work() as expecting to
be called with the mutex held (by renaming the function to
rescheduleWithMutexHeld(), then drop the mutex locking from it.
After this change, a non-recursive mutex suffices, so save the memory
allocation and extra complexity involved with recursive mutexes.
Looking at the non-QT_CONFIG(thread) code in rescheduleWithMutexHeld(),
one might be tempted to expect a recursive mutex, since that code
calls QHostInfoRunnable::run() directly, which, in turn, recurses into
QHostInfoLookupManager whence control came, under mutex lock. But in
non-QT_CONFIG(thread) builds, QMutex is but an empty shell, all of its
operations are no-ops, so no possibility for deadlock, either.
Change-Id: Ic01d90c2ed3995b66ccf946d146fdaa6f9af3d8b
Reviewed-by: MÃ¥rten Nordheim <marten.nordheim@qt.io>
Diffstat (limited to 'src/network/kernel/qnetworkinterface.h')
0 files changed, 0 insertions, 0 deletions