Date: Fri, 23 Jul 2021 13:39:27 -0700
On Friday, 23 July 2021 13:26:49 PDT Tony V E wrote:
> Does Qt hold a lock on the current slot when calling the slot?
Slots are not objects that can be locked. They are just functions.
> Boost.Signals2 doesn't lock the *list* of slots, but locks the individual
> slot.
>
> If another thread tries to disconnect the currently executing slot (say,
> because the slot target is being deleted) then it *must* wait for the slot
> to finish (else the slot might crash).
> If it must wait, it must hold a lock.
Right, the list is locked, but gets unlocked before every slot is called. So
those things end up operating independently. If the signal activation decided
to call that slot before it was disconnected, then it will get called. If the
disconnection happened first, then it won't.
> Qt (I think) avoids this because it uses an event queue - slots across
> threads are not called directly, they are queued. When an object is
> deleted, you "just" need to remove the to-be-called slot from the queue.
> The Qt idea that an object "lives" on a specific thread is a great way of
> dealing with many things.
Only for Qt::QueuedActivation. Qt::DirectActivation (which is the default for
target objects living in the current thread) does not queue up. It does as
described above: drop the lock, call, reacquire the lock.
As for queued activations already queued but not yet delivered, the
destruction of the target object removes all pending events from the event
queue.
> Without a separate (global/findable) queue, you either hold a lock (risking
> deadlock) or don't hold a lock and risk crashing.
Or you drop the lock and don't crash.
The connection list has a flag saying "in use", which means the list can't be
shrunk or garbage collected. Disconnections can still happen by removing the
effect of the entry in the list, but the size of list doesn't change.
Then we just need to prevent livelocks: what happens if you *connect*
something else to the same signal that is being activated, every time that a
given slot is activated?
> Does Qt hold a lock on the current slot when calling the slot?
Slots are not objects that can be locked. They are just functions.
> Boost.Signals2 doesn't lock the *list* of slots, but locks the individual
> slot.
>
> If another thread tries to disconnect the currently executing slot (say,
> because the slot target is being deleted) then it *must* wait for the slot
> to finish (else the slot might crash).
> If it must wait, it must hold a lock.
Right, the list is locked, but gets unlocked before every slot is called. So
those things end up operating independently. If the signal activation decided
to call that slot before it was disconnected, then it will get called. If the
disconnection happened first, then it won't.
> Qt (I think) avoids this because it uses an event queue - slots across
> threads are not called directly, they are queued. When an object is
> deleted, you "just" need to remove the to-be-called slot from the queue.
> The Qt idea that an object "lives" on a specific thread is a great way of
> dealing with many things.
Only for Qt::QueuedActivation. Qt::DirectActivation (which is the default for
target objects living in the current thread) does not queue up. It does as
described above: drop the lock, call, reacquire the lock.
As for queued activations already queued but not yet delivered, the
destruction of the target object removes all pending events from the event
queue.
> Without a separate (global/findable) queue, you either hold a lock (risking
> deadlock) or don't hold a lock and risk crashing.
Or you drop the lock and don't crash.
The connection list has a flag saying "in use", which means the list can't be
shrunk or garbage collected. Disconnections can still happen by removing the
effect of the entry in the list, but the size of list doesn't change.
Then we just need to prevent livelocks: what happens if you *connect*
something else to the same signal that is being activated, every time that a
given slot is activated?
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Received on 2021-07-23 15:39:31