Sorry, one more question... is it safe to fire up multiple dtrace_hdl_t
within a process?
Ryan
Jon Haslam wrote:
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.
But I don't think you are. If all you are doing is:
syscall:::entry
/pid == 1234/
{
@[probefunc] = count();
}
then all you need to do is call into dtrace periodically from
your consumer and consume the data. No need to have a victim to
do that.
I think the confusion may be that, originally, you were wanting to
have some mechanism where you had a probe (pid$target::foo:entry)
from which you could extract data that was being collected via
a copyout? I've got the heebie-jeebies just thinking about it.
This just isn't the way to do it and it's not going to work. The
consumer approach is what you need if the clause above is the
kind of thing you're after. Honest.
Jon.
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
