Re: Patch: CLONE_PPID, CLONE_WAIT, CLONE_SUSPENDED

Mike Touloumtzis (miket@geoworks.com)
Sat, 31 Jul 1999 13:13:23 -0700


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/