On Thu, Aug 24, 2000 at 11:46:52PM +0100, Alan Cox wrote:
> > Uh ? It should be already de-POSIXed. For "regular" processes,
> > SIGOVERKILL should probably just act like SIGKILL. Still leaves the
> > issue that tools to kill processes may need to know about the new
> > signal too.
>
> Numerous apps rely on knowing SIGKILL kills stuff dead. This hack is simply
> uglier than handling these few special cases.
Well, you are probably right but as long as the process actually does
die eventually, I think it works. That's why a lib_pthreads control
user space daemon seems plausible.
>
> Lets be honest SIGSTOP and SIGKILL are not critical fast paths for signals
> and with the thread group id Linus proposed we have a chain of tasks for the
> thread group so we are talking about adding a chain of code to signal a
> thread group that only has to deal with a few signals
I hate the idea of adding in-kernel synchronization/locks to deal with
a really stupid design -- POSIX signals/threads are best at arms
length.
And I like the idea of pushing the complexities of shared signal stuff
to processes that insist on using them. Pthread_kill makes sense,and
kill(threaded_process,... ) makes sense if the signal handlers are
global to the threaded process. That's why I like the idea of the root
thread getting signals and having the option of sending them off to
other threads. Once you have that, it's more tempting to think of things
like this SIGOVERKILL -- but maybe Alsmberger's name is a tipoff.
-- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:15 EST