fs: fix leak of end listener in ReadStream

[coderaiser]

When read is end, it leaves listener of end event.
This could be checked this way:

var fs      = require('fs'),
    read    = fs.createReadStream(__filename),
    write   = fs.createWriteStream(__filename + '-copy');

read.pipe(write);

read.once('end', function() {
    var listeners = read.listeners('end');
    console.log('' + listeners[0])
});

The code will log this function:

function () {
    if (this.autoClose) {
      this.destroy();
    }
  }

Version of iojs is:

> iojs -v
v1.8.1

[mscdex]

Has this caused a problem for you? The stream is not re-usable after it ends, so there shouldn't be a need to manually remove listeners.

Additionally, using .once() is slower (currently) than .on() because the former creates a new closure every time.

[coderaiser]

Additionally, using .once() is slower (currently) than .on() because the former creates a new closure every time.

Any way in fs once used 5 times and on used only once.

It's about leaking listener, why don't just remove it when it no need? It would simplify work for garbage collector and make code little bit cleaner.

I found this when wrote tests for pipe-io module. It simplifies work with streams. I checked that no listeners from this module is leaking to result streams, and found out that node listeners is leaking.

[brendanashworth]

Sorry for letting this sit for so long. I think it makes sense - LGTM, even if its just theoretical. @mscdex do you have an opinion against this? (I think the .on() vs .once() is a good point, too)

[mscdex]

@brendanashworth Something very similar to this was already discussed in #1510 and as far as I can tell it was decided it was a non-issue.

[brendanashworth]

@mscdex wow, that's an impressive drawing. Thanks for enlightening me.

This is probably a non-issue too, then. I'll close. Thanks for the pull request, though.