volatile inplace_function fails to compile about sg14

[Quuxplusone]

I am 99.999% confident that you don't need this ability. As you say, "I'm admittedly not entirely sure how necessary it is ... I don't feel safe having to omit volatile" — but as engineers we should deal in actualities, not "feelings." For now, I recommend that you do

#define Volatile

Volatile inplace_function<int()> f;
Volatile int x = f();

etc., and reopen this issue only if that solution produces incorrect or inefficient codegen for your program.

[phillipjohnston]

I use inplace function in multiple embedded programs as callbacks w/ the exact usage you describe. Volatile is not necessary.

[phillipjohnston]

I'm also not sure what exactly a volatile inplace_function would accomplish. You're telling the compiler not to perform read or write optimizations related to that variable. It makes sense for variables representing hardware registers, but not something like inplace_function. Also worth re-stating: volatile != atomic.

[TBBle]

Wouldn't volatile be appropriate if the function variable itself, e.g., f, was set in both the general code and the interrupt handler? The volatile would ensure the mainline code doesn't cache the function pointer's target between invocations if the interrupt handler has been run.

Perhaps there's rules for interrupt/signal handlers in C++ that mean this isn't necessary, but I haven't checked.

Something like:

volatile inplace_function<void(Status, bool /*isTerminal*/)> progress;

void do_thing(auto status_callback)
{
 f = callback;
 set_signal_handler(signal_hander);
 if (f) f(STARTING, false);
 open(thing); // Signal handler could run here
 if (f) f(COMPLETED, true);
 f = {};
 set_signal_handler({});
}

void signal_handler()
{
 if (f) f(SIGNALLED, true);
 f = {};
}

It seems that without volatile, that second if (f) in do_thing might be optimised away.

[Quuxplusone]

@TBBle: In your sample code, what prevents the signal handler from possibly running during the assignment f = {} in do_thing? If it ran in the middle of that assignment, it'd see f in a bad (half-assigned) state.

Real code that wants to do this kind of thing (and I'm not sure there is any) should probably store their callback in an atomic_shared_ptr<inplace_function<Sig>> f or an atomic<inplace_function<Sig>*> f, not a (non-atomic) inplace_function<Sig> f which is susceptible to tearing.

[TBBle]

Huh, yeah. For some reason I was thinking that signals only went off when control was handled to the kernel/libc using something like open. Weird...

Anyway, you're right. A totally-async signal does mean you need an atomic to be able to write to it at all.