Jon Haslam wrote:
1. Bad Things can happen if I use libdtrace and my process doesn't
exit cleanly (e.g. killed by debugger). Scary! This is why my app
currently forks dtrace(1M) instead of using libdtrace(3LIB)
directly.
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.
2. Using libdtrace just makes me a consumer (like dtrace(1) is), but
would still require me to parse the output of printa. Granted,
cutting it down to two kernel round trips is an improvement, but
still not particularly "clean" from my perspective.... especially
if I wanted a script to actually use that value in some way
(though in my current situation that's not an issue)
Using libdtrace gives you the cleanest method to do this with. There
are other mechanisms which you could use to periodically import
performance data which would work and I'm sure others may well
chime in with suggestions. Yes, with libdtrace you would have to do
some leg work yourself with coding but the joy and pleasure it
will give you will far outweigh any pain you may have encountered
along the way :-) .
Have a go. You know you want to.
For now I agree it's the cleanest approach... but is it feasible to
implement the ability to just read the aggregate directly inside a
script? You know you want to ;)
Ryan
_______________________________________________
dtrace-discuss mailing list
[email protected]
