dtrace-provider
Advanced tools
Comparing version 0.0.4 to 0.0.5
@@ -21,1 +21,4 @@ dtrace-provider - Changes | ||
Probe objects are made available to Javascript. | ||
* 0.0.5: | ||
Revert changes to make probe objects available. |
{ | ||
"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"], |
@@ -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 |
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"]; }); | ||
15
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. |
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
New author
Supply chain riskA new npm collaborator published a version of the package for the first time. New collaborators are usually benign additions to a project, but do indicate a change to the security surface area of a package.
Found 1 instance in 1 package
0
71098
44
89