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.