P4
While looking at JDK-8292695, I saw that we never explicitly unblock SIGPIPE and SIGXSFZ for hotspot threads like we do it for other signals we handle.
See `os_posix.cpp`, `signal_sets_init()`.
This is usually without consequences (unless we use signal chaining):
1) it is highly probable that they are already unblocked. Threads inherit blocking mask from their parents and processes from their parents, and the usual state is that these are unblocked anyway. But if a parent blocks them, they are now blocked in the VM too.
2) These signals are asynchronous, so receiving them while blocked probably does no harm (unlike synchronous error signals). And since all we do is ignore them explicitly and deliberately (to forestall their default action of killing the process) that's usually fine.
However, if we use signal chaining, user code may expect SIGPIPE and SIGXFSZ but will not get them.
Therefore we should explicitly unblock them like we do unblock all other hotspot-owned signals, to deliver them to callers via chaining, and also to reduce confusion.
See `os_posix.cpp`, `signal_sets_init()`.
This is usually without consequences (unless we use signal chaining):
1) it is highly probable that they are already unblocked. Threads inherit blocking mask from their parents and processes from their parents, and the usual state is that these are unblocked anyway. But if a parent blocks them, they are now blocked in the VM too.
2) These signals are asynchronous, so receiving them while blocked probably does no harm (unlike synchronous error signals). And since all we do is ignore them explicitly and deliberately (to forestall their default action of killing the process) that's usually fine.
However, if we use signal chaining, user code may expect SIGPIPE and SIGXFSZ but will not get them.
Therefore we should explicitly unblock them like we do unblock all other hotspot-owned signals, to deliver them to callers via chaining, and also to reduce confusion.