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

> 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/

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