Re: external systemtap meeting notes 20070816

[Roland McGrath <roland at redhat dot com>]

> > If A and B each got its own engine, then what would uprobes's callback
> > do?  If the callback eats the SIGTRAP, then the 2nd handler never gets
> > called.  If it doesn't eat the SIGTRAP, the probed process takes the
> > SIGTRAP and dies.  We could work up some new way that A and B could
> > coordinate this sort of thing, but then we're back to needing some sort
> > of shared (among instrumentation modules) data structures.  And what we
> > have now works just fine.
> 
> This is probably related to Roland's "engine interaction" note
> (http://tinyurl.com/22jt2o).  It would be nice if concurrent engines
> could nest transparently - or failing that, at least be aware of each
> other enough to get this right.

cf https://www.redhat.com/archives/utrace-devel/2007-September/msg00007.html

The future non-signal mechanism I described there can have a reporting
interface that lets an engine say "I induced this" while letting other
engines still see it, in case two have that same answer for a single
occurrence.  That is, it wouldn't cause any signal if any engines at all
claimed it, yet multiple engines could always see it.  This addresses the
part of the breakpoint interaction problem that Jim described here.

The other part of the problem is insertion/removal.  Naive non-cooperation
works if they literally nest, but not if removal order is not LIFO.  
I don't have any implicit-communication solution for that off hand.


Thanks,
Roland