[fulafel]

It's very different since at random points of your program your signal handler is caleld asynchronously, and you can only do a very limited signal-safe things there, and the flow of control in your i/o, logic etc code has no idea it's happening.

tldr; it's very different.

[fc417fc802]

Well at least in this case the timing won't be arbitrary. Execution will have blocked waiting on the read and you will (AFAIK) receive the signal promptly in this case. Since the code in question was doing IO that you knew could fail handling the situation can be as simple as setting a flag from within the signal handler.

I'm unclear what would happen in the event you had configured the mask to force SIGBUS to a different thread. Presumably undefined behavior.

> If multiple standard signals are pending for a process, the order in which the signals are delivered is unspecified.

That could create the mother of all edgecases if a different signal handler assumed the variable you just failed to read into was in a valid state. More fun footguns I guess.

[xmcqdpt2]

> Since the code in question was doing IO that you knew could fail handling the situation can be as simple as setting a flag from within the signal handler.

If you are using mmap like malloc (as the article does) you don't necessarily know that you are "reading" from disk. You may have passed the disk-backed pointers to other code. The fact that malloc and mmap return the same type of values is what makes mmap in C so powerful AND so prone to issues.

[fulafel]

Yes, and for writing (the example is read-write) it's of course yet another kettle of fish. The error might never get reported at all. Or you might get a SIGBUS (at least with sparse files).

[ozgrakkurt]

Signals are extremely bad to work with. Would rather do error handling in javascript. It feels like trying to write low level primitives in rust or trying to learn c++. There are so many edge cases that I start questioning what am I doing with my life