There is a complicating factor here. What if it is a virtual function?
Are you going to (silently/hidden) block reentrancy for all derived members
or just in that class? Calling a virtual function could skip that level of
the object inheritance tree and call a much further derived class/member
that was not marked noreenteranct. And then how would you handle it if a
further derived function did a base chaining call
virtual void Derived::Foo() { ...; Base::Foo(); ...; }
but virtual void Base::Foo(); was marked noreenteranct

Would you block only external calls to your noreenteranct member or any
call including from derived classes.
You could/would potentially block functionally of a derived class that
needed the functionality in your class or your base (that may not have been
marked noreenteranct).
What about a pointer to member functions to a base/derived class are you
going to block them too?
Your noreenteranct flag would affect the functionality of derived classes
(without much warning) and change the entire idea of the design &
architecture. Seems like too big of an ask.
Are you going to have one of your hidden implementation flags for every
function marked as noreenteranct in your class?

Please see the other private message I sent you about correcting your
design issue with your GUI notify/update/change and where/how you should be
handling these in the right place in the event model.

Most event driven/state machine models that do this kind of thing miss
critical events because they were blocked and thus become very fragile and
buggy requiring other patches to overcome the first patches. That should
be the first sign that something is wrong with your design. Why doesn't
everybody else doing a GUI type interface have this same type of reentrancy
problem?

About the messages about the open ended undecided issues, is this
per-instances, per-thread, or per-class.
Undecided Issues==Can of worms. No good/bast answer


On Sun, Feb 12, 2023 at 6:51 PM Bjorn Reese via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 2/13/23 02:18, Frederick Virchanza Gotham via Std-Proposals wrote:
>
> > thinking. A new idea can be totally new and unique, without any
> > precedents, and still be a good idea.
>
> The problem you have described is a classic for event-driven
> architectures.
>
> Your solution is return a magic value when busy. Throwing exceptions or
> returning std::optional or std::expected would have been more general.
> This was explored in P0779.
>
> Others here have suggested a "wait until available" solution using
> mutexes.
>
> Another common solution is to enqueue a task for later execution, thus
> breaking the recurrence. Networking TS proposes a library solution for
> this.
>
> Your proposal should examine the design space and explain why it is
> better than the alternatives.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>