Cool writeup but... Signals are not some opaque or roundabout feature to do this. Signals are a thing for a reason and this is how it's implemented in any threaded I/O library I've read.
Ye, but signals are cumbersome and a foot gun. Should a library ever install signal handlers? What about languages with runtimes? Ever read the spec on how go handles signals differently depending on how it is compiled?
You don’t have to do any significant work within the signal handler itself. In fact, the signal handler can literally be empty. What matters is that as long as SA_RESTART is not set, after the signal handler runs, the interrupted syscall fails with errno set to EINTR. Then the code that did the syscall can check whether a cancellation occurred (and retry the syscall if not).
Disclaimer: I haven’t looked at Zig’s implementation; I’m only going off how the Unix APIs work.
Comments
Cool writeup but... Signals are not some opaque or roundabout feature to do this. Signals are a thing for a reason and this is how it's implemented in any threaded I/O library I've read.
Ye, but signals are cumbersome and a foot gun. Should a library ever install signal handlers? What about languages with runtimes? Ever read the spec on how go handles signals differently depending on how it is compiled?
how do they handle that malloc aint async signal safe?
You don’t have to do any significant work within the signal handler itself. In fact, the signal handler can literally be empty. What matters is that as long as SA_RESTART is not set, after the signal handler runs, the interrupted syscall fails with errno set to EINTR. Then the code that did the syscall can check whether a cancellation occurred (and retry the syscall if not).
Disclaimer: I haven’t looked at Zig’s implementation; I’m only going off how the Unix APIs work.