Messages in this thread | | | From | Eric PAIRE <> | Subject | Re: Patch: CLONE_PPID, CLONE_WAIT, CLONE_SUSPENDED | Date | Tue, 27 Jul 1999 12:56:55 +0200 |
| |
> On Fri, 23 Jul 1999, Khimenko Victor wrote: > > > In <199907230748.CAA22390@isunix.it.ilstu.edu> Tim Hockin (thockin@isunix.it.ilstu.edu) wrote: > > > Here is the result of all the various inputs on CLONE_PPID/CLONE_PPIDOK, > > > CLONE_WAIT, and CLONE_SUSPENDED. > > > > Looks like the only not solved problem is "signals to process", right ? > > What about LinuxThreads ? > > > > I'm hoping to begin working on it, with a purely userspace solution: the > manager thread will get all signals for the process, and will dispatch > them to the threads. To do this, it will change the thread's pgrp (but > not its own), so pgroup-wide signals go to the manager to be dispatched. > > Actually, there _is_ one more unsolved problem: core dumps. When a > thread gets killed by the kernel for doing something illegal (SIGILL / > SIGSEGV / whatever), the complete process is supposed to be dumped. I > still haven't thought up a suitable solution for this... > Last year, after having developed the linuxthread debug support in GDB, I made a small proposal to allow a flexible support for multithreaded core while letting the thread manager decide what to do on signal receiving (actually whether or not it wants to implements the POSIX semantics): The basic idea is to configure for each thread what to do when a core dump is required (namely whether to actually dump the core to a file, or to write the faulting context in its own thread memory).
The mechanism will be the following, mainly implemented in user mode in the LinuxThread package: 1) For each thread created, a special area is reserved in the shared memory for a fault context to be written by the kernel.
2) All threads but the thread manager uses a special sysctl() to specify that instead of doing a core dump, the fault context must be written at the reserved area.
3) Under a fault, a thread context is written at its own place, and the thread manager is signaled that a thread has died with a signal (no core is actually dumped, but the fault context in the memory); the thread manager then implements the POSIX behaviour by broadcasting the signal to all threads but itself.
4) All threads receive the signal and the kernel writes their current context in their reserved area.
5) The thread manager waits for the death of all threads, and then sends to itself the received signal, which actually dumps the core (since the thread manager has not required special handling of core dump).
6) GDB is actually updated to handle the context of all linuxthread not from the multithreaded core format, but from the context area reserved for each threads but the thread manager. Notice that even if not modified, GDB is able to read a correct core format and to tell which signal has been received, but is unable to give more informations.
The main advantage of this schema is that the core is not multithreaded within its own format, but via a special format fixed by the user-level package. The kernel does not need to know anything about the core format for multithreaded applications (It may also work for core formats that do not handle multithreads, like a.out). The modifications in the kernel are very limited, since the behaviour in the signal handling functions are preserved. Only the core-dumping mechanism has to be modified to handle the fact that the context writing is required instead of the core dump (plus the sysctl() handling).
Hope this will give some implementation ideas, -Eric +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Eric PAIRE Web : http://www.ri.silicomp.com/~paire | Group SILICOMP - Research Institute Email: eric.paire@ri.silicomp.com | 2, avenue de Vignate Phone: +33 (0) 476 63 48 71 | F-38610 Gieres Fax : +33 (0) 476 51 05 32 | FRANCE
- 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/
| |