5 ms·

How would you fix signals and do you propose a complete set of patterns for safe concurrency? And so why is there limited scope for signal handlers? Should yo

How would you fix signals and do you propose a complete set of patterns for safe concurrency? And so why is there limited scope for signal handlers? Should you use signal handlers with eBPF?

kstenerud 2mo ago
It's not really possible to make them safer without hurting performance. Signals break the C virtual machine guarantees (atomics, memory consistency, register consistency, etc), and the only way to re-establish them for edge cases like signals would be to cripple the rest of the program with extra checks (basically making ALL data volatile).
- westurner 2mo ago
  I guess that's why unix signals are not appropriate for concurrent message handling
Joker_vD 1mo ago
> How would you fix signals Well, I'd probably just get rid of them entirely? For example, Windows functions just fine without them: SIGINT is emulated by the kernel doing essentially pthread_create(..., &registered_ctrl_c_handler) — which neatly sidesteps the question of "what existing thread receives the signal" by answering "none of them" — SIGILL/SIGSEGV are handled with SEH because that's essentially what they are, the exceptions; SIGSTOP/SIGKILL are instead proper process-management "syscalls" SuspendProcess/TerminateProcess (seriously, why is what essentially are ioctls on a pidfd was bolted onto signals, it makes zero sense), and most of other asynchronous signals are just done via different channels. Honestly, the most useful things about the signals is that they will interrupt your syscalls with EINTR so your code may have a chance to look around and notice things that happened while it was blocked inside the kernel. > a complete set of patterns for safe concurrency? Pfft, that's easy: synchronous rendezvous and message queues; alternatively, CSP. We've known this answer since the early 70s.

5 ms·

How would you fix signals and do you propose a complete set of patterns for safe concurrency? And so why is there limited scope for signal handlers? Should yo

by westurner 2mo ago

How would you fix signals and do you propose a complete set of patterns for safe concurrency? And so why is there limited scope for signal handlers? Should you use signal handlers with eBPF?

kstenerud 2mo ago
It's not really possible to make them safer without hurting performance. Signals break the C virtual machine guarantees (atomics, memory consistency, register consistency, etc), and the only way to re-establish them for edge cases like signals would be to cripple the rest of the program with extra checks (basically making ALL data volatile).
- westurner 2mo ago
  I guess that's why unix signals are not appropriate for concurrent message handling
Joker_vD 1mo ago
> How would you fix signals Well, I'd probably just get rid of them entirely? For example, Windows functions just fine without them: SIGINT is emulated by the kernel doing essentially pthread_create(..., &registered_ctrl_c_handler) — which neatly sidesteps the question of "what existing thread receives the signal" by answering "none of them" — SIGILL/SIGSEGV are handled with SEH because that's essentially what they are, the exceptions; SIGSTOP/SIGKILL are instead proper process-management "syscalls" SuspendProcess/TerminateProcess (seriously, why is what essentially are ioctls on a pidfd was bolted onto signals, it makes zero sense), and most of other asynchronous signals are just done via different channels. Honestly, the most useful things about the signals is that they will interrupt your syscalls with EINTR so your code may have a chance to look around and notice things that happened while it was blocked inside the kernel. > a complete set of patterns for safe concurrency? Pfft, that's easy: synchronous rendezvous and message queues; alternatively, CSP. We've known this answer since the early 70s.