dtrace-provider
Advanced tools
Comparing version 0.0.6 to 0.0.7
@@ -27,1 +27,4 @@ dtrace-provider - Changes | ||
Fix for segfault trying to use non-enabled probes (Mark Cavage <mcavage@gmail.com>) | ||
* 0.0.7: | ||
Fix for multiple enable() calls breaking providers. |
{ | ||
"name" : "dtrace-provider", | ||
"version" : "0.0.6", | ||
"version" : "0.0.7", | ||
"description" : "Native DTrace providers for node.js applications", | ||
@@ -5,0 +5,0 @@ "keywords" : ["dtrace"], |
@@ -64,4 +64,10 @@ # dtrace-provider - Native DTrace providers for Node.js apps. | ||
The data types supported are "int" and "char *". There's definitely | ||
scope to improve this, with more elaborate argument handling. | ||
scope to improve this, with more elaborate argument handling - see | ||
TODO.md | ||
You can only create a provider once - although you don't have to do it | ||
immediately, once you've set up a provider you can't change its | ||
definition. It should be possible to enable updates - again, see | ||
TODO.md. | ||
## CAVEATS | ||
@@ -73,5 +79,7 @@ | ||
callback, but too much work needs to be done before that's | ||
checked. Improving this may imply changes to the API shown in the | ||
example above. Please see TODO.md for the details. | ||
checked. That being said, unless your (disabled) probes are | ||
insanely hot, this shouldn't be a problem. | ||
Please see TODO.md for the details. | ||
## CONTRIBUTING | ||
@@ -78,0 +86,0 @@ |
@@ -0,1 +1,13 @@ | ||
// expected output: | ||
// | ||
// $ sudo dtrace -Z -n 'nodeapp*:::probe1{ printf("%i %i %i %i %i %i", arg0, arg1, arg2, arg3, arg4, arg5); }' \ | ||
// -n 'nodeapp*:::probe2{ printf("%s %s %s %s %s %s", copyinstr(arg0), copyinstr(arg1), copyinstr(arg2), copyinstr(arg3), copyinstr(arg4), copyinstr(arg5)) }' \ | ||
// -c 'node test/dtp.js' | ||
// | ||
// dtrace: description 'nodeapp*:::probe1' matched 0 probes | ||
// dtrace: description 'nodeapp*:::probe2' matched 0 probes | ||
// CPU ID FUNCTION:NAME | ||
// 1 3421 func:probe1 1 2 3 4 5 6 | ||
// 1 3422 func:probe2 a b c d e f | ||
var d = require('../dtrace-provider'); | ||
@@ -7,3 +19,4 @@ var dtp = d.createDTraceProvider("nodeapp"); | ||
dtp.fire("probe1", function(p) { return [1, 2, 3, 4, 5, 6]; }); | ||
dtp.fire("probe2", function(p) { return ["hello, dtrace", "foo", "bar", "baz", "fred", "barney"]; }); | ||
dtp.fire("probe2", function(p) { return ["a", "b", "c", "d", "e", "f"]; }); | ||
setTimeout(function() { }, 1000); |
26
TODO.md
# dtrace-provider - TODO | ||
## FEATURES | ||
### Complex Arguments | ||
Right now the argument types are just 'int' and 'char *'. There's no | ||
possibility of passing, say, javascript objects through DTrace. | ||
It seems like there's two things that need to be done here: | ||
* Find the right format for taking complex argument values through DTrace | ||
* Find a way to teach DTrace about what we're emitting | ||
### Dynamic Updates | ||
These providers are already pretty dynamic in that you get to create | ||
them based on runtime data - but you only get to do that once, for | ||
each provider. | ||
It'd be nice to be able to modify providers that already exist, | ||
updating or adding to their probe definitions. This opens up the | ||
possibility of providers which dynamically add probes based on data, | ||
and given a high level of collusion between a JIT and the provider | ||
management, much lower overhead dynamic-language tracing by having the | ||
JIT output tracepoints directly. | ||
## PERFORMANCE | ||
@@ -33,1 +58,2 @@ | ||
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
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
78
97
40775
19