This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: uprobes: keep thread blocked after the handler returns
- From: Jim Keniston <jkenisto at us dot ibm dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: systemtap at sourceware dot org
- Date: Thu, 02 Aug 2007 13:57:05 -0700
- Subject: Re: uprobes: keep thread blocked after the handler returns
- References: <20070802211901.3153C4D04B5@magilla.localdomain>
On Thu, 2007-08-02 at 14:19 -0700, Roland McGrath wrote:
> > Why not just prevent the handler from returning until you want the
> > thread to unblock? The handler could sleep on something trigger from
> > user space.
>
> That is a no-no for a utrace callback. It prevents other tracing
> facilities from doing anything useful.
Yeah, you're pretty adamant about that in Documentation/utrace.txt, but
I always wondered why. Using gdb, I can stop a traced app and keep it
stopped all weekend. If nobody else is using the app, why should
anybody care?
Sure, utrace allows multiple facilities to trace the same app, and we
may see circumstances where multiple users skew each others' results by
tracing the same app with blocking handlers. That doesn't seem like a
very good reason for preventing utrace handlers from doing useful stuff
that can't be accomplished without blocking.
Jim