Date: Fri, 23 Jul 2021 16:26:49 -0400
On Fri, Jul 23, 2021 at 12:38 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
std-proposals_at_[hidden]> wrote:
> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
-- Be seeing you, Tony
Received on 2021-07-23 15:27:04