On 7/22/21 8:09 PM, Andrey Semashev via Std-Proposals wrote:
> 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.
>

How could you deal with asynchronous callbacks then?


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


In my perspective the cost / benefits is minimal / worth it for all the
abstraction it gives you as proven by Qt and my experience working on
military vehicles (state machines) that the hardware ultimately
controls. But that's just my perspective.

-- 
*Phil Bouchard*
Founder & CTO
C.: (819) 328-4743
Fornux Logo <http://www.fornux.com>