What is the opsem of signal/interrupt handlers.

[chorman0773]

Signal Handlers (and interrupt handlers, which are basically equivalent) are a fun thing to specify.

Signal Handlers have been modeled as separate threads, but this is incorrect: Because the code that is interrupted is running on the same thread, you cannot, e.g. acquire a mutex, or perform I/O from a signal handler. (C, C++, and POSIX each individually maintain a more comprehensive list of what you can and cannot do: https://en.cppreference.com/w/cpp/utility/program/signal, https://en.cppreference.com/w/c/program/signal, https://man7.org/linux/man-pages/man7/signal-safety.7.html).

Some things that are clear, at least to me:

• non-mut, impl Freeze statics should be accessible and yield proper values when read,
• non-mut statics with Atomic* types should be accessible and be usable as normal,
• You can call any function that C allows you to call in a signal handlers.

Note: This question only tracks asynchronous signals and asynchronous interrupts. I'd assume the answer to "What can a signal caused by raise do" is "Anything raise could do if it was an arbitrary opaque function".

Further sub-questions:

• What about the FP environment?

[RalfJung]

You said in the meetings there are examples where treating a signal handler as an independent thread causes not just liveness issues but UB?

[bjorn3]

non-mut, impl Freeze statics should be accessible and yield proper values when read,

In C you did have to use volatile reads and writes, sig_atomic_t or atomic_signal_fence for that, right?

[RalfJung]

In C you did have to use volatile reads and writes, sig_atomic_t or atomic_signal_fence for that, right?

Do you? Even in C concurrent non-atomic reads of the same data from multiple threads are allowed. So I would expect "concurrent" non-atomic reads of the same data from a thread and its signal handler to be equally permitted.

[chorman0773]

You said in the meetings there are examples where treating a signal handler as an independent thread causes not just liveness issues but UB?

The most direct examples are "Call an AS-unsafe function". I don't know a specific example of pure-rust, but I bet I could come up with one.

In C you did have to use volatile reads and writes, sig_atomic_t or atomic_signal_fence for that, right?

The C equivalent would be (at file scope, or static at function scope)

const int X = 0;

Do you? Even in C concurrent non-atomic reads of the same data from multiple threads are allowed. So I would expect "concurrent" non-atomic reads of the same data from a thread and its signal handler to be equally permitted.

You would think. Technically, it would have an unspecified value. I'd be quite shocked if that value was any different from it's initialized value, though.

[chorman0773]

C++17's definition does fix that, by redefining it's access model in terms of it's MT Memory Model (and constant initialization happens-before every evaluated statement in the entire program).

[bjorn3]

In C you did have to use volatile reads and writes, sig_atomic_t or atomic_signal_fence for that, right?

Do you? Even in C concurrent non-atomic reads of the same data from multiple threads are allowed. So I would expect "concurrent" non-atomic reads of the same data from a thread and its signal handler to be equally permitted.

For a non-atomic value you did have a data race without volatile or a signal fence and with an atomic value you did miss synchronization between the store and the start of the signal handler (so the signal handler could run before the store) or between the end of the signal handler and the load (so the signal handler could run after the load) unless you explicitly synchronize in some way for an async signal handler as far as I understand. For atomics this is UB free, but likely not what you want. On the other hand for sync signals I did expect a synchronization to happen between the function raising the signal and the signal handler itself, but it seems to not be guaranteed.

https://en.cppreference.com/w/c/program/signal

On entry to the signal handler, the state of the floating-point environment and the values of all objects is unspecified, except for

• objects of type volatile sig_atomic_t
• objects of lock-free atomic types (since C11)
• side effects made visible through atomic_signal_fence (since C11)

On return from a signal handler, the value of any object modified by the signal handler that is not volatile sig_atomic_t or lock-free atomic(since C11) is undefined.

[chorman0773]

Do keep in mind that my statement was about non-mut impl Freeze statics.
They only have constant initializaition, and cannot be modified during execution.

That being said, your analysis is correct as to C (though, as I mentioned, C++17 would allow the C++ equivalent).

[RalfJung]

@bjorn3 We are specifically talking about the read-only case. There are no stores. Without stores, there cannot be data races nor missed synchronization.

[chorman0773]

@bjorn3 is correct though, that in C it would have an unspecified value absent actual synchronization with a proper fence or atomic operation. I think it's reasonable to adopt something closer to the C++ definition, though.

[RalfJung]

That seems like an oversight that was fixed by C++17 properly integrating this into their concurrency model.

[chorman0773]

Perhaps. I haven't heard of a proposal fixing it for C23, though, so the earliest it fixes in C is going to be 2029.

For rust, though, I"d definitely go with C++'s model, though.

Frankly, seems easier to make operational before even considering what it implies.

[RalfJung]

Another interesting question for signal handlers is the FP environment. I think we want to allow inline assembly blocks to change the FP unit to a different state, perform some operations, and then change it back. However that means we must declare float operations as not-async-signal-safe, since the signal handler might encounter the FP environent in a non-default state which leads to Rust floating-point operations executing incorrectly.

(Thanks to @bjorn3 and @digama0 for pointing that out.)

[RalfJung]

Or is that handled by the register save/restore logic when "context-switching" between the actual thread and the signal handler?

[comex]

Based on some testing, it varies:

• Linux modifies the floating point mode on signal entry and exit (setting it to a default value on entry and restoring the previous value on exit).
• macOS modifies the floating point mode only on exit (restoring it to the previous value, which is also seen inside the signal handler).
• Windows does not modify the floating point mode on either entry or exit (at least for this method of raising a signal).

So indeed, a portable signal handler should assume the FP environment is in an unknown state, and make sure it's still in that state before returning. After all, it's not just inline assembly that might temporarily change the FP environment, but also external code called through FFI.

[Lokathor]

I suspect that counting interrupt handlers and signal handlers as just one category is too much of a simplification.

Putting it perhaps overly broadly, interrupt handlers are usually used in a no_std environment when a hardware situation occurs, while signal handlers are usually used in a std-like environment when a software situation occurs. I have less experience with signal handlers, but it seems just from reading this thread like they have more restrictions than what an interrupt handler has to think about.

Should we try to split up the situation?