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
<elad.benisr...@gmail.com> 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 <gaurav.va...@gmail.com> 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.
