dtrace-provider
Advanced tools
Comparing version 0.0.2 to 0.0.3
@@ -14,1 +14,3 @@ dtrace-provider - Changes | ||
* 0.0.3: | ||
Builds to a stubbed-out version on non-DTrace platforms (Mark Cavage <mcavage@gmail.com>) |
var sys = require("sys"); | ||
var DTraceProvider; | ||
function DTraceProviderStub() {} | ||
DTraceProviderStub.prototype.addProbe = function() {}; | ||
DTraceProviderStub.prototype.enable = function() {}; | ||
DTraceProviderStub.prototype.fire = function() {}; | ||
try { | ||
var binding = require('./DTraceProviderBindings'); | ||
var DTraceProvider = binding.DTraceProvider; | ||
var dtrace_provider = true; | ||
DTraceProvider = binding.DTraceProvider; | ||
} catch (e) { | ||
sys.puts(e); | ||
var dtrace_provider = false; | ||
DTraceProvider = DTraceProviderStub; | ||
} | ||
exports.DTraceProvider = DTraceProvider; | ||
exports.createDTraceProvider = function(name) { | ||
return new DTraceProvider(name); | ||
}; | ||
}; |
{ | ||
"name" : "dtrace-provider", | ||
"version" : "0.0.2", | ||
"version" : "0.0.3", | ||
"description" : "Native DTrace providers for node.js applications", | ||
@@ -5,0 +5,0 @@ "keywords" : ["dtrace"], |
@@ -55,4 +55,4 @@ # dtrace-provider - Native DTrace providers for Node.js apps. | ||
The nature of this extension means that support must be added for each | ||
platform. Right now that support is only in place for OS X, 64 bit, | ||
but Solaris x86 and 32 bit support is on the way. | ||
platform. Right now that support is only in place for OS X, 64 bit and | ||
Solaris, 32 bit. | ||
@@ -59,0 +59,0 @@ ## LIMITATIONS |
@@ -1,2 +0,2 @@ | ||
var d = require('dtrace-provider'); | ||
var d = require('../dtrace-provider'); | ||
var dtp = d.createDTraceProvider("nodeapp"); | ||
@@ -3,0 +3,0 @@ dtp.addProbe("probe1", "int", "int", "int", "int", "int", "int"); |
27
TODO.md
@@ -5,4 +5,29 @@ # dtrace-provider - TODO | ||
## ARGUMENT TYPES | ||
### Disabled Probe Effect | ||
The main problem here is how much work needs to be done to get to the | ||
point we can use the is-enabled check. | ||
While the is-enabled check allows us to avoid invoking the probe-args | ||
callback with its potentially expensive args-gathering work, we still | ||
do the following when a disabled probe is fired: | ||
* Dispatch Fire method from JS | ||
* Obtain DTraceProvider instance from V8 context | ||
* Args checking (must get a probe name and a callback) | ||
* Linear search through provider's probes for probe name | ||
* Invoke the is-enabled stub | ||
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
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
37322
40