Crash at runtime if a signal is encountered (for now).

[vext01]

See: ykjit/ykdocs#4

[bjorn3]

I am not quite sure what this issue is about @vext01.

[ltratt]

I think this is referring to potential problems if a signal interrupts execution while we have PT turned on. I think Edd came up with a fix for that (maybe we just ignored the resulting trace? I don't remember!) but I might be wrong.

[bjorn3]

I think a user setting a signal handler is even more rare than using catch_unwind. Basically the only crates I know of that do it are wasmtime (to catch signals inside wasm code), libstd (SIGSEGV handler to print a nice message on stack overflow followed by an abort) and ctrlc which runs catches SIGINT and sends a byte over a pipe before continuing executing. This doesn't require the trace to be invalidated for as long as it isn't traced itself.

[ltratt]

I have a Rust program which sets signals :) Also, user programs in the languages implemented in yk may set signals (doing so is semi-common in Python). But "handling" it can simply mean "throw away any PT trace which was interrupted by a signal."

[playXE]

I think a user setting a signal handler is even more rare than using catch_unwind. Basically the only crates I know of that do it are wasmtime (to catch signals inside wasm code), libstd (SIGSEGV handler to print a nice message on stack overflow followed by an abort) and ctrlc which runs catches SIGINT and sends a byte over a pipe before continuing executing. This doesn't require the trace to be invalidated for as long as it isn't traced itself.

I'm using signals and windows exceptions to implement GC safepoints and all it is in Rust. I don't think it is a good idea to interrupt trace when it is just GC safepoint?

[ltratt]

If we record a trace and that thread happens to enter GC mode as the result of a signal, we probably do want to throw the trace away (unless it's an explicit call to the GC, but that wouldn't be the result of a signal). However, we're currently doing a fairly hefty reorganisation of yk/ykrustc so this detail might change (though probably not I suspect).

[playXE]

@ltratt What if this wasn't entering GC cycle but signal happened because thread had to suspend for GC to run in another thread?

[ltratt]

Isn't that the same thing?

[playXE]

Suspending a thread to wait for GC to finish is simple spin loop while GC cycle is not.