Re: accessing each pthread's context
- From: "bcreane" <bcreane@xxxxxxxxx>
- Date: 21 May 2006 21:03:07 -0700
I agree that sending a signal (via pthread_kill?) to all the other
threads that haven't asserted, and then appending a stack backtrace to
an open file would most likely work. My hesitation comes from the
nondeterministic nature of mixing threads and signals and adding the
messiness of having the app in a "crazy" state. For example, you might
get into a situation where you're not sure if the last thread has
checked in -- is it time to exit(), or should we give that last
recalcitrant thread a chance to perform its backtrace. The difference
to me is getting a core dump immediately after an exception/signal, or
building up a core dump over time by letting each thread add its
context to the snapshot.
That's why Paul Pluzhnikov's suggestion of creating a monitor process
that has some of the features of a debugger is appealing to me. In
fact, that would be probably be a useful opensource project ... call it
"overlord" as in "I for one welcome our new ..."
.
- References:
- accessing each pthread's context
- From: bcreane
- Re: accessing each pthread's context
- From: davids
- Re: accessing each pthread's context
- From: Clifford Heath
- Re: accessing each pthread's context
- From: bcreane
- Re: accessing each pthread's context
- From: davids
- accessing each pthread's context
- Prev by Date: Re: accessing each pthread's context
- Next by Date: OT [Re: accessing each pthread's context]
- Previous by thread: Re: accessing each pthread's context
- Next by thread: Re: accessing each pthread's context
- Index(es):
Relevant Pages
|