Messages in this thread | | | Subject | Re: Never mind. Re: Signal left blocked after signal handler. | From | Albert Cahalan <> | Date | 27 Nov 2003 10:45:39 -0500 |
| |
On Thu, 2003-11-27 at 04:11, Ingo Oeser wrote: > On Wednesday 26 November 2003 22:53, Albert Cahalan wrote:
> [2.4 vs. 2.6 wrt. thread synchronous signals] > > How about making the process sleep in a killable state? > > > > This is as if the blocking was obeyed, but doesn't > > burn CPU time. Only a debugger should be able to > > tell the difference. > > This has 2 problems: > > 1) Servers and PID files or servers and simple monitoring software. > 2) Processes spawned from init, which will not respawn.
It has benefits:
1. Continuous respawning is no good. 2. If the processes sleeps, you can attach a debugger.
The obviously correct behavior is to go back into user space, likely to take the signal again. The only thing wrong with this is that it eats CPU time. So _pretend_ to do that. Have the process sleep, ideally with an "R" state as seen in /proc, and maybe even go back to the crazy loop if someone attaches a debugger.
The crazy loop is most correct though. It's what the user asked for. It perfectly handles the case of a repeating SIGFPE (blocked) followed by some other thread unmapping a page of instructions or data that turns the SIGFPE into a SIGSEGV.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |