zlib.*Sync methods fire asynchorous callbacks

[ChALkeR]

https://github.com/iojs/io.js/blob/v2.0.1/lib/zlib.js#L458 — this line is called even for *Sync methods. That's not the only one.

See #1479 and #1665 (comment)

[ChALkeR]

@trevnorris

[ChALkeR]

@Qard It's not the garbage collector that is broken as you supposed in #1665 (comment), it's zlib.*Sync methods not working as expected.

[ChALkeR]

That's since 07d3b21, I suppose.
I might be wrong, I haven't tested that commit.
@isaacs

[Qard]

I didn't say garbage collection was broken, I said your expectations of it were incorrect and that there needed to be documentation to explain that.

In this case, the objects are not collectable simply because they are still accessible by future code--the close emitting function. That can be fixed.

JavaScript in general is not a good language for sync looping though, as you need to trigger GC manually and hope that enough things are collectable to not rapidly run out of memory.

[trevnorris]

@ChALkeR Can you give me a code example where that manifests itself as a problem?

[ChALkeR]

@trevnorris I initially posted that to the issue: #1665 (comment) has the code sample, #1479 is the original report.

@targos commented 20 days ago
I was running a script to read sequentially a lot of gzipped files, and print on stdout the result of a computation for each file.
After about 16'000 files, the process just stopped and Killed was printed on the terminal.

[trevnorris]

@ChALkeR Thanks. IMO it's a bug.

[ChALkeR]

@indutny On a side note, zlib.* methods (both sync and async) are collected only during full GC runs. Could something be done with that?
Edit: It's Buffers fault: #1671.

[ChALkeR]

@bnoordhuis
But the reason to defer the event is to prevent infinite recursion. I'm not sure if this is fixable without breaking something else.

Is that the case for *Sync methods? Will it be safe not to defer the event for *Sync methods?

[bnoordhuis]

Is that the case for *Sync methods?

Yes. Events always need to be asynchronous. The problem in a nutshell:

// example 1
function next() {
  var t = task();
  t.on('complete', next);
}

// example 2
function next() {
  task(next);
}

In the first example, if 'complete' is synchronous, you don't have time to attach an event listener.

In the second example, if the callback is synchronous, you get infinite recursion.

[ChALkeR]

@bnoordhuis But those events are not public in *Sync case and can't be used outside of the core code. I am not even sure if they are needed in the *Sync case.

[trevnorris]

@bnoordhuis just curious, is there ever a time where a synchronous task allows adding event listeners?

[piscisaureus]

@bnoordhuis just curious, is there ever a time where a synchronous task allows adding event listeners?

It happens in other places too (e.g. fs.createSyncReadStream(), process.stdout).
It pretty much always causes problems, and I think it's a broken pattern that we shouldn't use.

[trevnorris]

@piscisaureus Sorry, I should have clarified the question. Is there ever a time where the public API allows attaching events to a synchronous task?