Is there any modern software that actually appreciates or uses SIGPIPE ?

@bagder I doubt there's any modern software that cares about more than 4 or 5 signals, maybe 6 for daemons.

@aris agreed!

@bagder You mean this thing?
```
lib/isc/loop.c: * Always ignore SIGPIPE.
lib/isc/loop.c: ignore_signal(SIGPIPE, SIG_IGN);
```

@ondrej in libcurl we have this convoluted setup as we ignore the signal within the library's own calls and then we restore things back on return in case the application is doing something else... !

@bagder @ondrej lmao this seems like great behavior for users, but kind of a pain for libcurl developers. Thank you for your service 🫡

@bagder I've thought about this for CLIPSockets, as it must handle many concurrent connections in a single-threaded CLIPS-based rules engine.

I ended up ignoring this pipe with signal(SIGPIPE, SIG_IGN);, but I think it's possible to make use of it.

Signals are tricky because previous signals of the same type may have been dropped by the time you are in your signal handler. If you have multiple clients connected simultaneously, handlers must be aware of that. It's tricky to think about 😄

@bagder @ondrej you ought to be able to check if there was a previous handler set, and stop worrying about it if there wasn't any.

@bagder
Er, yes? I have had reasons to check EPIPE on write(2) to see if it's just the reader stopping or if it's a "real" error...

@levitte a return code (or errno) is not a signal though

@hyc @ondrej and *when* would that check be to be sure that there is not a new one introduced in the mean time?