Date: Fri, 23 Jul 2021 09:27:50 -0400
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.
It is *possible* to implement synchronous connections in Qt, but it is
somewhat awkward and IME virtually never done.
> 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.
> 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.
It is *possible* to implement synchronous connections in Qt, but it is
somewhat awkward and IME virtually never done.
> 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.
-- Matthew
Received on 2021-07-23 08:27:54