Node.js - 如果在 I/O 和回调仍在运行时调用 response.end 会发生什么？

Question

In Node.js, what happens if call "response.end()" while my I/O calls and/or callbacks are still executing? As in the following:

var app = http.createServer(function(request, response) {
    response.writeHead(200, { 'Content-Type': 'text/plain'});

    fs.writeFile('baz', 'contents', function() {
                  myOtherFunc();
                  response.end('Second response.end'); 
    }); 

   response.end('First response.end');
});

Specifically:

1. Is the HTTP connection freed up immediately upon calling the first response.end? (Bonus points: how can I inspect this myself?)
2. Can I use this to perform arbitrarily complex/costly computation, even synchronous ones, within myOtherFunc? Since the connection has been freed the client is no longer waiting? (Or is there any reason why not?)
3. Can this be used as a paradigm to perform 'background' tasks upon invocation, with 'myOtherFunc' being an arbitrary background task -- since it is essentially now running "in the background"?

Answer 1

Calling response.end doesn't stop any asynchronous code that's still executing. You'll might see weird behavior though if you try to end or modify a response that's already been ended. So, basically yes to all. I'll admit though, I'm not an expert on how node handles its HTTP connections behind the scenes.

Answer 2

I haven't tested, but:

1. Given the asynchronous nature of node, it's possible the stream wouldn't be freed up before the second response.end is called, but I doubt you can rely on that... at some point the connection must close and trying to send new data will "at best" fail silently.
2. The connection is freed and the client won't be waiting... for that request, at least, but costly synchronous computations will hold up the rest of your application, full stop. Any subsequent requests will have to wait for your work to finish, and odds are response will be gone if you don't get to it by the next few ticks.
3. Learn more about node's single threadedness. node works not by doing a bunch of things at once, but by not blocking while it's waiting. There is no "background" unless you explicitly spawn your own thread to do something.

Edit: I'm working with the assumption that the response stream is closed explicitly, with the end call, rather than just sitting out there waiting to be garbage collected. My assumption is it's just done asynchronously rather than waiting on completion to continue on, and if you get there within the next couple ticks of the event loop, it may still be allocated.

Edit Again: Your intrepid answerer has searched tirelessly through the node source and confirmed that, indeed, two calls to end should indeed not work, the second should be short circuited by the OutgoingMessage.finished property (see lines 499-501 and 541)