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.


Sent from my BlackBerry portable Babbage Device
  Original Message
From: Andrey Semashev via Std-Proposals
Sent: Thursday, July 22, 2021 8:10 PM
To: std-proposals_at_[hidden]
Reply To: std-proposals_at_[hidden]
Cc: Andrey Semashev
Subject: Re: [std-proposals] Signals & Slots

On 7/22/21 9:32 PM, Tony V E via Std-Proposals wrote:
>
>
> On Thu, Jul 22, 2021 at 2:28 PM Thiago Macieira via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> wrote:
>
> On Thursday, 22 July 2021 11:17:11 PDT Tony V E via Std-Proposals wrote:
> > Signals-slots are fundamentally difficult/impossible without a
> central
> > message pump (like Qt has), or maybe executors.
>
> The cross-thread slot-delivery of a signal emission, agreed.
>
> For immediate execution, no, you don't need a message pump. At that
> point, the
> signal-slot mechanism is basically an M:N callback mechanism. We
> could have
> this portion first.
>
>
> You can do that, but it is not thread safe. Maybe worth standardizing,
> maybe not.

Boost.Signals2 is thread safe, in some sense at least.

Though in my practice I eventually ended up replacing uses of
Boost.Signals2 signals with explicit callbacks. Not because I was
unsatisfied with Boost.Signals2 in particular, but because I found the
concept of signals more difficult to work with safely and more difficult
to maintain and debug.

Signals probably do have their uses, but not as many as it might seem.
I'm not sure they are worth standardizing.

-- 
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals