Jonathan Adams wrote:
On Fri, Jun 26, 2009 at 03:15:16PM +0100, Jon Haslam wrote:
Can you provide any specifics regarding these bad things?
Well, libdtrace is rather underdocumented, but according to the folks
behind TclDTrace, "Note that *dtrace_close* is needed to prevent an epic
fail. It does a major cleanup, that involves restoring the state of all
grabbed processes, which may be all processes in the system..."
Now, if somebody with internal knowledge could reassure us all that,
say, the kernel always calls dtrace_close during process cleanup, then
libdtrace becomes much more attractive.
It is true that you need to call dtrace_close() to release children
you are controlling. Look at the source for dtrace(1M) or plockstat(1M)
and you'll see that the have signal handlers setup which call into
dtrace_close for SIGTERM and SIGINT.
However, why are you worried about leaving children in an odd state?
By the look of the example you gave you're not controlling children
are you? You just want to compile a D script and read the data
periodically and do something with that. If so, you're just doing
regular consumer activities - it doesn't matter that the script you
injected is interested in the consumer. You're not dealing with victim
processes there's no need to worry about the subtleties of that.
In particular, this shouldn't be an issue unless you are enabling foo12345:::
probes (that is, any providers with PIDs in them)
Ah, but I am... that was the way for my app to tell dtrace it wants the
latest stats... the question was how to get the answer back since I
can't copyout() the aggregation's value.
DTrace isn't "controlling" the process, though, at least not by the
pid-grabbing-proc-locking-debugger-excluding definition. Is it
controlling a process that requires cleanup or use of the pid provider?
If it's only the latter, what happens if the dtrace consumer and the
process being traced are the same? A not-clean process exit would take
both the consumer and the process with, so unless there's stuff to
clean up in the kernel...
Ryan
|
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
