The current implementation is that if I create a new engine in response to an exec (when called from some other engine's report_exec callback), and set that engine's flags to be notified of execs, the new engine gets notified of the exec that's already underway. This turns out to be rather inconvenient for uprobes, but is it counterintuitive?
Roland thinks not. We agreed to air the issue here. Of course it could have implications for other types of events, but exec is the one that most interests me. Comments welcome. Jim (01:02:05 PM) jkenisto: Roland, could you look at Comment #6 in [systemtap] PR 7082? (01:03:47 PM) jkenisto: Is it desired (by you) behavior for utrace_report_exec to notify an engine that is created after utrace_report_exec starts its callbacks? (01:04:29 PM) jkenisto: It'd be nice for me/uprobes if it didn't do that. (01:04:52 PM) jkenisto: I can adjust uprobes, but I wanted to check with you first. (01:04:52 PM) rmcgrath: a newly attached engine goes on the end of the list, so it's gotten to later in the same loop (01:05:10 PM) jkenisto: Yeah, I figured that's what's happening. (01:05:34 PM) jkenisto: Seems counterintuitive, though. (01:05:36 PM) rmcgrath: can discuss the api issue on utrace-devel, but it doesn't seem wrong to me. you asked for notifications, the event is happening, you got notified. (01:06:27 PM) rmcgrath: i guess i think of the engines as unrelated to each other in the utrace api, so the new engine is a new engine attached to a task that happens to have an exec to report right then
