[DynInst_API:] urgent RFC: dyninst/proccontrol callbacks

[Bill Williams <bill@xxxxxxxxxxx>]

Folks--

As any of you who've worked on (or with) proccontrol know, it's a 
complex beast. (If you don't know, Bart and I will be happy to tell war 
stories over beer...) One of the particular areas of complexity is 
stopping a process in order to deliver a user-level callback; another is 
deciding what operations are legal from within a callback (and what a 
user can request post-callback).
We've discovered that LWP exit callbacks being allowed to stop an entire 
process are a bad idea (and near-impossible to implement correctly on 
linux in the face of signals): 
https://github.com/dyninst/dyninst/issues/100. As a consequence, we're 
looking into whether and how we can redesign our callback mechanisms, 
both in Dyninst and in Proccontrol, to be more restrictive--in 
particular, to disallow process-level stops as return values.
Urgent questions follow; negative answers are at least as valuable as 
positive ones.
1) Do you use ProcControl callbacks for thread/process events?
2) If so, which ones, and for what purpose(s)?
3) Do you use BPatch callbacks for thread/process events?
4) If so, which ones and for what purpose(s)?
5) If you don't use callbacks but are emulating their functionality 
(e.g. with breakpoints or instrumentation), can you describe your use 
case for the benefit of folks who are currently using callbacks?
Any/all feedback is greatly appreciated; while I doubt that these 
changes will make it into 9.2, redesigning these interfaces and our 
internal client code that relies on them is going to take some thought 
and some testing, and I want to ensure that we can get the bug I've 
linked above fixed for a 9.3 release.
Thanks for your time.

--bw