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@lists.isocpp.org <mailto:std-proposals@lists.isocpp.org>> 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