From: KOSAKI Motohiro Date: 2011-11-10T11:21:41+09:00 Subject: [ruby-core:40902] Re: [ruby-trunk - Bug #5556] SIGHUP no longer ignored when sent to process group from a subprocess > The use case is any reason someone would send a signal to the process group but not want the parent process to abort. I'm quite sure there is existing code that depends on this behavior even by accident. The fact that it changed will affect some programs that have previously not ignored HUP, so people will likely get puzzling process exits in cases such as I discovered here by accident, ie on process subprocessing worker processes. Guys, I asked you practical and real world usecase. > I really don't care what the behavior is as long as it is documented and tested. If you can point me to tests for this, I'll adapt them for RubySpec. > > I have no idea what you mean by "signal handler is per-process resource", how would it not be a per-process resource? Or do you have a definition of per-process where process is not an OS process? How does per-process and thread-safety relate? Seems like we should have a glossary of terms as MRI defines them to avoid some confusion here. man sigaction.