dtrace-provider - npm Package Compare versions

Comparing version 0.0.4 to 0.0.5

CHANGES.md

		@@ -21,1 +21,4 @@ dtrace-provider - Changes
		Probe objects are made available to Javascript.

		* 0.0.5:
		Revert changes to make probe objects available.

package.json

		{
		"name" : "dtrace-provider",
		"version" : "0.0.4",
		"version" : "0.0.5",
		"description" : "Native DTrace providers for node.js applications",
		@@ -5,0 +5,0 @@ "keywords" : ["dtrace"],

README.md

		@@ -29,21 +29,14 @@ # dtrace-provider - Native DTrace providers for Node.js apps.
		var dtp = d.createDTraceProvider("nodeapp");
		var p1 = dtp.addProbe("probe1", "int", "int");
		var p2 = dtp.addProbe("probe2", "char *");
		dtp.enable();

		At this point the provider has been created - the probes will show up
		in a listing from dtrace -l.

		You can fire the probes using a method on the provider:

		dtp.addProbe("probe1", "int", "int");
		dtp.addProbe("probe2", "char *");
		dtp.enable();
		dtp.fire("probe1", function() { return [1, 2]; });
		dtp.fire("probe2", function() { return ["hello, dtrace"]; });

		or a method directly on the probe objects:
		This example creates a provider called "nodeapp", and adds two
		probes. It then enables the provider, at which point the provider
		becomes visible to DTrace.

		p1.fire(function(p) { return [1, 2]; });
		p2.fire(function(p) { return ["hello, dtrace"]; });
		The probes are then fired, which produces this output:

		Firing the probes produces this output from dtrace:

		$ sudo dtrace -Z -n 'nodeapp*:::probe1{ trace(arg0); trace(arg1) }' \
		@@ -80,3 +73,4 @@ -n 'nodeapp*:::probe2{ trace(copyinstr(arg0)); }'
		callback, but too much work needs to be done before that's
		checked.
		checked. Improving this may imply changes to the API shown in the
		example above. Please see TODO.md for the details.

		@@ -83,0 +77,0 @@ ## CONTRIBUTING

test/dtp.js

		var d = require('../dtrace-provider');
		var dtp = d.createDTraceProvider("nodeapp");
		var p1 = dtp.addProbe("probe1", "int", "int", "int", "int", "int", "int");
		var p2 = dtp.addProbe("probe2", "char ", "char ", "char ", "char ", "char ", "char ");
		dtp.addProbe("probe1", "int", "int", "int", "int", "int", "int");
		dtp.addProbe("probe2", "char ", "char ", "char ", "char ", "char ", "char ");
		dtp.enable();
		p1.fire(function(p) { return [1, 2, 3, 4, 5, 6]; });
		p2.fire(function(p) { return ["hello, dtrace via probe", "foo", "bar", "baz", "fred", "barney"]; });
		dtp.fire("probe1", function(p) { return [1, 2, 3, 4, 5, 6]; });
		dtp.fire("probe2", function(p) { return ["hello, dtrace via provider", "foo", "bar", "baz", "fred", "barney"]; });
		dtp.fire("probe2", function(p) { return ["hello, dtrace", "foo", "bar", "baz", "fred", "barney"]; });

TODO.md

		@@ -20,3 +20,14 @@ # dtrace-provider - TODO

		Even with the probe objects available from 0.0.4, there's still quite
		a lot going on.
		The fix I'd like to make here is to allow probes to exist as JS
		functions themselves, so that the calling code can directly invoke the
		function to fire the probe, avoiding the search by name. In this
		situation we could also defer checking the arguments until the probe
		is actually fired.

		With these changes, the disabled-probe overhead should be reduced to a
		JS method call, and then the invocation of the is-enabled stub.

		The API change to support this would be to return these probe
		functions from provider.addProbe(), rather than calling through
		provider.fire(), though that could easily remain for backwards
		compatibility.

dtrace_provider.cc

Sorry, the diff of this file is not supported yet

dtrace_provider.h

Sorry, the diff of this file is not supported yet

test/dtp.js~

Sorry, the diff of this file is not supported yet

wscript

Sorry, the diff of this file is not supported yet

New alerts