On Thursday, 22 July 2021 23:25:14 PDT Tony V E via Std-Proposals wrote:
> Boost Signals2 is about as thread safe as possible (and I helped with the
> design of it), but a slot can still deadlock in a weird edge case.
>
> As long as you don't grab locks in your slots you are fine, but that is
> easier said than done - people call functions that call functions that...
> grab locks that you aren't aware of.
We have the same problem in Qt.
As a rule of thumb, never call back to user
code with acquired locks and signal emission counts as calling back to user
code.
This is the fundamental piece.
Does Qt hold a lock on the current slot when calling the slot?
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.
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.
Without a separate (global/findable) queue, you either hold a lock (risking deadlock) or don't hold a lock and risk crashing.
Moreover, we often have also to deal with the current object (this) having
been deleted in that very callback. So the rule of thumb is to emit signals at
the very end of your function, after you've dropped the locks and are ready to
return any way.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel DPG Cloud Engineering
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals