> > I think of the interface as asynchronous at base. > > This certainly seems like a departure from the approach employed by > systemtap, gdb, ptrace, utrace, *probes, etc., where the traced thread > is essentially suspended from its normal operation while the > instrumentation code handles the event.
That is not what I was talking about at all. I'm talking about how the debugger application interacts with the facility, not what the facility does for it. It's asynchronous because you can get a notification triggered by debugged thread A while you are waiting for the answer to a request you made about debugged thread B. > It seems to me that we ought to consider the possibility of > multithreaded tracer apps [...] All such possibilities are open. This is part of what multiple channels in a session would be about. Like I said, I was starting with just the simplest case before getting into all that. > A key question is whether a traced thread can block waiting for the > tracer app to handle the event. Ptrace certainly supports this. But as > I recall, you're rather adamant that a utrace callback (other than > report_quiesce) should NOT block waiting for something to happen in user > space -- e.g., because a SIGKILL can't get delivered during that time. This is a misunderstanding. Sorry I haven't been clear. You can help me improve the documentation, and you can write wiki pages about the issues that have concerned you to help others understand them. All the talk about "don't block" is in the context of documentation for writers of kernel module code. I'm talking about "blocking" there in the specific technical sense in kernelspeak. This is purely a subject of in-kernel implementation, not a feature constraint. In both the original API and the new utrace API, well-behaved tracing engines use the utrace infrastructure rather than "blocking" kernel-internal calls to implement the behavior they want. This is an important implementation detail for writing the kernel modules that implement the interface. It has nothing to do with what semantics the interface can choose to present. Thanks, Roland
