lkml.org 
[lkml]   [1999]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Patch: CLONE_PPID, CLONE_WAIT, CLONE_SUSPENDED

This appears to be another argument for more flexible
signal semantics (which are currently being worked on,
I think). Suppose you have groups of threads akin to
process groups. Deliver a signal to all threads in a
multithreaded process; then the next one to be scheduled
will handle the core dump.

miket

On Sat, Jul 31, 1999 at 12:28:59PM +0300, Alon Ziv wrote:
>
> ...
>
> So, we must create the coredump immediately when the fault is detected;
> and this (IMO) means it must be done in the kernel, as we don't want to
> implement some extremely complex inter-task messaging mechanism to make
> sure the manager is the next task which will run.
>
> To sum it up, it appears as if we'll have to use something like the patch
> that was recently posted that will produce a real threaded coredump for
> all tasks sharing the same mm, and possibly we'll also require a change in
> the fault handing logic so that after a force_sig the same task will
> _always_ go on running to handle the trap...
>
> -az
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:1.076 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site