Not sure exactly what use case Gaurav is interested in, but I was
interested in this thread because I think there is an unmet need around
logging which domain-attached context could help solve (even a single
pointer to a global instance). Logs are emitted everywhere across
application (and library) stack and in node, mostly via `console.xxx`. One
useful feature would be to allow, for example, correlating all console logs
emitted during the processing of an incoming request. A few logging
libraries do allow pushing context but they all require passing along some
state throughout the async hoops, which means modifying the way logging is
done throughout the entire stack.
I found the ability to push implicit context to logs pretty useful in
debugging large and chatty systems, and it is used in many environments. In
yakky synchronous multi threaded environments, it's easy to implement
nowadays using thread local storage. In the async environment of node I am
wondering if it requires some additional support.
I think proper support from node to this need would be valuable. Domains
seemed like a natural approach to me, given their basic attribute is
passing along implicit context across asynchronous call chains, and I ran
into `process.domain` following this thread of thought.
Cheers,
Elad.
On Wed, Jul 11, 2012 at 12:51 AM, Isaac Schlueter <i...@izs.me> wrote:
> 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.
>
--
Elad.
