On Wednesday, 14 November 2012 22:04:15 UTC, Forrest L Norvell wrote: > > > > Forrest L Norvell > Node.js agent engineer > | E [email protected] <javascript:> | C (415) 823-6356 | T > @othiym23<http://twitter.com/othiym23> > | G github.com/othiym23 | W newrelic.com > *(* *(* **)**)* *New Relic* > > On Wednesday, November 14, 2012 at 1:35 PM, pie_lard wrote: > > Suppose node were changed to remove the feature that lets domains track > EventEmitters. So domain.add(), .remove() and .members would all be > removed. The code that automatically adds new EventEmitters to the active > domain (if there is one) would also be deleted. Finally, suppose .bind() > and .intercept() were also removed. > > As an aside, you should only have to call domain.{add,remove} on a handle > or an emitter yourself under very specific (and rare) conditions. > > That would just leave domain.run() - plus the ability to create new > domains and possibly nest them. > > Would that be enough to effectively recreate synchronous stack-based > exception handling? > > No, and I'll explain why below. > > My answer would be yes - and in fact it would remove my connection-pool > problem altogether without any need for the 3rd-party module authors to > change anything. > > To put it another way; in what real-world circumstances would you need the > features I just removed? > > Please understand I ask this as a bit of a node noob ;) It's not a > criticism of domains - I would like someone to explain why I'm wrong about > this. > > The problem is it's impossible to know in advance whether a chunk of code > is going to use EventEmitters or not, and without domain code there to wrap > them, you'd lose the necessary state to tie a specific request to a > specific domain. Consider the following (buggy / incomplete) Express > handler: > > app.get('/test', function (req, res) { > var d = domain.create(); > d.on('error', function (error) { res.send(500, > {"content-type":"text/plain"}, error.stack); }); > d.run(function () { > fs.readFile(FILENAME, 'utf-8', function (err, contents) { > // process.domain should be available here > res.send(contents.replace(/:/gm, '/')); > }); > }); > }); > > > The call to res.send is going to happen several passes through the event > loop after the initial handler is called. It's entirely possible that in > the time the file is read from disk, another several requests to that > handler are going to have come in to the server. Without dealing with the > EventEmitters, how will any errors emitted inside the fs.readFile callback > be connected back to the enclosing domain? > > Maybe this is what I'm misunderstanding! I was under the impression that your example would in fact work (ie. that your domain handler would catch an error thrown by the res.send() call).
The docs say: Additionally, callbacks passed to lowlevel event loop requests (such as to fs.open, or other callback-taking methods) will automatically be bound to the active domain. If they throw, then the domain will catch the error. Doesn't that imply that you've done all you need to do in the above code? That just by starting the chain of callbacks inside run() that the active domain will persist through them? And that as you're creating a new domain per request the domains won't get confused - the correct res object will be available when an error is thrown? BTW: I didn't mean to imply that the domain code inside node could do this without wrapping EventEmitters or something similar. Just that (a) it should do so behind-the-scenes and (b) the wrapping shouldn't take the form of binding the EventEmitter to whatever domain happens to be active when the emitter was created. F > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
