On 7/23/21 4:27 PM, Matthew Woehlke wrote:
> On 7/23/21 3:21 AM, Andrey Semashev via Std-Proposals wrote:
>> On 7/23/21 6:43 AM, Phil Bouchard via Std-Proposals wrote:
>>> 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.
>
> Qt assuredly disagrees.
>
> While there is some overlap, signals and callbacks also differ
> significantly. *Callbacks* are inherently synchronous; that is, it is
> not unusual for a callback to perform some action that the issuing
> entity depends on. This also implicitly means it is difficult to have
> multiple callbacks for the same event. Callbacks, you might say, are
> *proactive*.
>
> Signals are inherently *reactive* and asynchronous. An event occurs, and
> some other code may *or may not*, at some point in time, react to that
> event. *Even within a single thread* is is conceptually not the case
> that this reaction must occur immediately. Many-to-many connections are
> thus a non-issue, because the entity issuing the event *does not care*
> whether anything is done with that event.

That's definitely not my understanding of what signals are. In my
understanding, a signal is a generalization of a function call - instead
of a single target function call, a signal may have multiple targets and
aggregates the results into one final result. In addition, signals
typically allow to abstract away the caller and the callees. This isn't
a distinctive feature though, since the same is possible with regular
function calls.

(A)synchronicity and thread locality of the call is an entirely separate
and orthogonal aspect of the call. Both regular functions and signals
can be invoked asynchronously and across threads, and signals are not
inherently asynchronous.

> It is *possible* to implement synchronous connections in Qt, but it is
> somewhat awkward and IME virtually never done.

I'm not talking about specifically Qt. In fact, I don't have much
experience with Qt to begin with.

>> 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.
>
> It sounds like what you consider "thread passing" is actually a better
> model for (Qt-like) signals than what *you* are calling "signals".
>
> I repeat: signals may be asynchronous *even on the same thread*. Some
> times you need to *force* this behavior. Most of the time you just don't
> care. Needing connections that are guaranteed synchronous is less common
> than not caring. Asynchronous dispatch ability is *fundamental* to how
> signals work, at least when you're talking about Qt-style signals.

Again, I don't dispute that signals can be asynchronous. But I disagree
that asynchronicity is an inherent feature of signals. We surely have
seen successful implementations of the concept that are synchronous.