Messages in this thread | | | Date | Sat, 31 Jul 1999 13:13:23 -0700 | From | Mike Touloumtzis <> | Subject | Re: 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/
| |