On 7/23/21 6:43 AM, Phil Bouchard via Std-Proposals wrote:
>
> On 7/22/21 11:33 PM, Phil Bouchard via Std-Proposals wrote:
>>
>>
>> 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:
>>>>
>>>> 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?
>>
>
> Sorry I meant: how could you deal with inter-thread signals / slots?

Thread passing and signals are two separate concepts, each being useful
on its own. IMHO, at its fundamental level, signals have to be
synchronous, like std::function is. You can implement inter-thread
callbacks on top of that interface.

Thread passing has no relation to the choice between signals and a
custom callback implementation. Really, all you need from a thread
passing library is to be able to schedule a function to be called in
another thread, and at that point it doesn't matter what that function
is - a signal or a custom callback.