Having got this far in the thread, I'm interested in the outcome, and I
would suggest writing a paper with a glossary and a proposal, inviting
feedback. Even if the feedback is "wait for executors to land" then you
have something in place for people to refer back to, rather than a thread
on a mailing list. PLUS you have a glossary so people's apprehensions of
the words signal, slot, callback, sender, receiver and so on are not
confused: everyone can say "C++ signals" rather than "Are you talking about
Qt signals?"

Even if it's only a couple of pages, at least it's a starting point. When I
was assisting with P0267 2D Graphics, this particular part was the source
of considerable discussion. Consider flagging SG13 and SG1 as your target
readers.

Cheers,
G

On Fri, 23 Jul 2021 at 23:50, Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Friday, 23 July 2021 15:11:12 PDT Tony V E wrote:
> > As for queued activations already queued but not yet delivered, the
> > destruction of the target object removes all pending events from the
> event
> > queue.
> >
> > Yeah, that's the special sauce that avoids the problems. In the general
> > (non-Qt) case, you don't have a queue mechanism to fall back on.
> [...]
> > You don't crash because you never delete an object from thread A while
> the
> > slot is running from thread B.
> >
> > In the non-Qt non-queue-available-for-threads world, you can't
> synchronize
> > the deletion from thread A with a slot from thread B.
>
> I see what you mean. Thanks for clarifying. This is another difference
> between
> the 3- and 4-argument versions of connect:
>
> connect(sender, &Sender::itHappened, [=] { receiver->act(); });
> vs
> connect(sender, &Sender::itHappened, receiver, [=] { receiver->act(); });
>
> The 3-argument version has no idea what the lambda it was passed does. The
> lifetime of the connection is bound to the sender only and the activation
> will
> always be direct.
>
> The 4-argument version has extra context. The lifetime of the connection
> is
> bound to both sender and receiver, so it's disconnected when either is
> destroyed, whichever happens first. That means it will not outlive the
> receiver and cause a dangling pointer dereference. And it'll also activate
> in
> the receiver's thread, as discussed.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DPG Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>