David Smith <[EMAIL PROTECTED]> writes:
> [...] >> 2. Why do we want utrace global tracing? >> From a systemtap point of view, we'd certainly use global tracing. I have a somewhat different take on this. This kind of interface would be nice to have in utrace only if it were significantly cheaper than doing what we do now: potentially attaching utrace-engines to each thread -- or (in the near future, systemtap bug# 6445) to subtrees of the process hierarchy. (An extra chunk of work per clone() may well be cheaper than extra work at every system call.) > Systemtap doesn't currently change outcomes in a callback, so reason > c. doesn't apply much. [...] Actually, this is the main reasons that utrace-level support sounds interesting to me. We have had requests for exposing some thread control primitives to systemtap probe handlers - to block/resume, send signals, that sort of stuff. *If* going through utrace (as opposed to a separate API) would make this smoother and compose better (should e.g. there be different systemtap scripts fighting over the threads), that could be worthwhile. - FChE
