undefined | Better HN

0 pointsratorx1y ago0 comments

I think that’s slightly orthogonal. It would still be safe, because you’d design around this restriction from the start, rather than accidentally call or mutate something you were not supposed to.

The problem with safe signal handling is that you need to verify that your entire signal handler call stack is async safe. Assuming purity is a stronger property, signal handling is a safe API without any more work.

The inflexibility due to the purity might cause other issues but that’s more a language level concern. If the signal handling API is safe and inflexible, it still seems better for a lot of use cases than an unsafe by default one.

0 comments

o11c1y ago

The real problem is that the compiler doesn't provide arbitrary function-colorings, only the a handful of builtins: `pure`, `const`, `noreturn`.

s-zeng1y ago

Monads can be thought of as arbitrary function colourings, hence the prior mention of Haskell potentially being a good fit. Of course monads are implementable in almost any other language, but few have as much syntax sugar or general library support as Haskell does, except maybe Ocaml

jandrese1y ago

Yeah, but how do you design a Monad that does the "tell this other thread to unblock and unwind its state because an external error has triggered? You know, the basic function of an interrupt?

ratorxOP1y ago

There’s two separate aspects here:

1) Monads used to restrict the computation available in the context of a signal handler (or function coloring etc, basically a way for a compiler or static checker to determine that a block of code does not call unsafe functions)

2) The actual process of handling a signal received by the signal handler

I think me and the parent are referring to 1). 2) is also important, but it is not a signal specific concern. Even without a signal handler, if you want to write an application which handles async input, you have to handle the case of processing the input to do something useful (eg. let’s say you are writing an HTTP server and want to have a network endpoint for safely killing the thing).

I think the generally recommended way to represent 2) in a pure way is to model the signal as a state machine input and handle it like all other communication.

j / k navigate · click thread line to collapse