> >> I'm interested to know if there's any programmatic interface to DTrace
> >> so an application could control dtrace probes and receive the raw data
> >> in a form it could easily use?
> >
> > There is a such an interface, with two language bindings: an undocumented
> > (but well-established
On Wed, Sep 26, 2007 at 03:25:11PM -0700, Bryan Cantrill wrote:
> There is a such an interface, with two language bindings: an undocumented
> (but well-established) C interface (libdtrace), and a documented JNI interface
> (see http://www.opensolaris.org/os/project/dtrace-chime/java_dtrace_api/).
Bryan Cantrill wrote:
> On Wed, Sep 26, 2007 at 03:01:37PM -0700, Greg wrote:
>> I'm interested to know if there's any programmatic interface to DTrace
>> so an application could control dtrace probes and receive the raw data
>> in a form it could easily use?
>
> There is a such an interface, wit
>>I'm interested to know if there's any programmatic interface to DTrace so an
>>application could control dtrace probes and receive the raw data in a form it
>>could easily use?
>>
>
>There is a such an interface, with two language bindings: an undocumented
>(but well-established) C interface
On Wed, Sep 26, 2007 at 03:01:37PM -0700, Greg wrote:
> I'm interested to know if there's any programmatic interface to DTrace so an
> application could control dtrace probes and receive the raw data in a form it
> could easily use?
There is a such an interface, with two language bindings: an
I'm interested to know if there's any programmatic interface to DTrace so an
application could control dtrace probes and receive the raw data in a form it
could easily use? It seems all the existing work is on human-oriented
interfaces involving writing scripts to do ad-hoc system management and
Hey David,
This looks a lot like the question you asked on July 19th of this year. We
determined that the problem then was caused by libproc exhausting the file
descriptor limit. Let us know if you already eliminated that cause.
http://www.opensolaris.org/jive/thread.jspa?messageID=138829
The
I have a dtrace script which works OK when grabbing a single pid:
pid$1:*::entry
{
self->depth++;
}
But if I extend it to try for 6 pids concurrently, it fails on the forth pid:
pid$1:*::entry, pid$2:*::entry, pid$3:*::entry, pid$4:*::entry, pid$5:*::entry,
pid$6:*::entry
{
self->depth++;
}
http://blogs.sun.com/jonh/
The esteemed Jon Haslam posted some slides with examples of new features
that went into DTrace since Solaris 10 was released.
Good stuff, and a tip-o-the-hat to Jon.
/jim
___
dtrace-discuss mailing list
dtrace-discuss@openso
On Thu, Sep 20, 2007 at 09:59:06AM +0100, Jon Haslam wrote:
> I actually did a presentation at last nights London OpenSolaris User
> Group meeting which went through some of the features that have been
> added since s10 released. I'll try and put the slides up on my blog
> sometime. There's nothing
"Daniel" == Daniel A Steffen <[EMAIL PROTECTED]> writes:
Daniel> I am pleased to announce the availability of a DTrace provider
Daniel> for Tcl. It is included in Tcl 8.4.16 (released on the
Daniel> weekend) as well as in Tcl 8.5b1 (due out later this week).
Thanks much Daniel.
--
Dave Marquardt
11 matches
Mail list logo
