Consider this the opposite of a blessing. That is not only an undocumented feature, but an undocumented implementation detail of an experimental feature. You can pretty well be assured it will change in a future release. (Though, not in v0.8.x, which is API and ABI frozen.) The reason that it's not documented is because it's sort of a kludgey way to keep track of the current domain, and we want to leave the option open for more elegant or performant approaches in the future.
If you want per-request storage, what's wrong with putting stuff on the request object like everyone else does? Sorry if I'm missing the point of your question here. "Thread-local" only really makes sense in servers that spawn a new thread (or thread-like thing) for each request. Node doesn't do that. It's relevant in those environments because threads can preempt one another, so you have to be careful to use thread-safe data structures or else you'll have problems. Node's JavaScript is single-threaded, and cannot be preempted, so you never have that issue. And child processes don't share memory (mostly) so you don't have corruption issues. So, (a) the thing you're talking about doesn't really exist, because (b) you probably don't actually need it. You've got global (which is per-process), module-local (the var's you define in your module), exports (specific to a module, but visible from the outside), and several objects relating to different conceptual constructs (like the req, the req.socket, the response, child processes, etc.) Your program isn't ever preempted, so "thread local" is not relevant here. On Tue, Jul 10, 2012 at 11:53 AM, Elad Ben-Israel <[email protected]> wrote: > Done a little bit of digging and found out the undocumented > `process.domain`, which actually allows one to access the current domain > from anywhere. This is very similar to "thread local storage", but it's way > awesomer because it automatically traverses async calls. > > For example (node 0.8.2): > > ``` > var domain = require('domain'); > var http = require('http'); > > function do_some_async_stuff(callback) { > setTimeout(function() { > console.log('url of current request is', process.domain && > process.domain.url); > return callback(); > }, 500); > } > > var server = http.createServer(function(req, res) { > var d = domain.create(); > > // attach `req.url` to the domain as arbitrary context > d.url = req.url; > > d.run(function() { > do_some_async_stuff(function(err) { > res.end('done'); > }); > }); > }); > > server.listen(5000); > ``` > > This is an undocumented feature so I would advise not to use it before > someone from node core gives their blessing. > > Any thoughts from the core maintainers on this? Why did you guys choose not > to document it? Any caveats that people should be aware of? > > Cheers, > Elad. > > On Wed, Jul 4, 2012 at 7:03 AM, Gaurav Vaish <[email protected]> wrote: >> >> Hi Elad, >> >> > As far as I know node does not support something like that. One idea >> > that >> > came to mind is to add support for associating arbitrary context to a >> > domain<http://nodejs.org/docs/latest/api/all.html#all_domain> and >> > extract it along the way. >> > >> > I was thinking on trying to hack something like that. Any thoughts? >> >> Do you already have some thoughts on the same? >> >> >> -- >> Happy Hacking, >> Gaurav Vaish >> www.m10v.com >> > > > > -- > Elad.
