> Open question: whether or not to allow the remaining threads to
> continue once the dump is completed, to abort them, or to signal
> them. Probably should be run time configurable.
I was expecting to take the Posix thread style viewpoint in which any
of the core dumping signals kill the _process_, so all of the threads
are necessarily dead thereafter since they have nowhere to live any
longer.
This approach is certainly what people migrating from other Unixen
expect. (And, killing everyone is also what Linux threads
implements).
Andreas Dilger <adilger@turbolinux.com> was kind enough to point out
that there have been a couple of recent postings (which I failed to
find in my original search :-() which claim already to have
implemented this, and provided patches :-
Terje Malmedal <tm@funcom.com>:
http://marc.theaimsgroup.com/?l=linux-kernel&m=96355845607151&w=4
The Malmedal patch is not actually a patch to generate a
multi-threaded core file, rather it generates a separate complete core
file for each thread. I will not consider this further.
Jason Villarreal <villarre@cs.ucr.edu>:
http://marc.theaimsgroup.com/?l=linux-kernel&m=96931745912910&w=4
The Villarreal patch is exactly the kind of thing I was thinking
of. It generates a standard multi-threaded ELF core file.
I _think_, but would need to read it in more detail to be sure, that
it assumes that all of the threads in the process are sent the
signal which forced the dump. It then lets the last one out actually
write the file including the thread specific data recorded by all of
the previous threads to exit.
Since the Villarreal patch exists and seems to do all that I wanted, I
don't propose to create a competing patch.
Maybe you kernel gurus could point out any problems with the Villarreal
approach ?
-- Jim
James Cownie <jcownie@etnus.com>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:27 EST