Read data asynchronously

[lukechilds]

Doesn't block while waiting for stdin to finish.

Discussed in #13

[SamVerschueren]

Could you rebase from master?

[lukechilds]

Am doing, gimme a second, jeez.

[lukechilds]

Sorted 😉

[SamVerschueren]

Sorry, didn't want to put pressure on you :).

[lukechilds]

Haha, no worries man I was just kidding.

[kevva]

It's already async (AFAIK), and this code is intentional. See eedcea4.

[lukechilds]

Are you sure? Does while (chunk = stdin.read()) not block?

[lukechilds]

When get-stdin subscribe to stdin, it blocks the process until something is written to stdin.

#13 (comment)

[lukechilds]

@SamVerschueren @kevva I just had another look at this and it is indeed currently async.

The difference is with the readable event (introduced in Streams2) you can choose whether to read the data now or later. With data you have to handle the data in the callback or you lose it forever. The current code uses the more advanced readable event but always handles the data straight away anyway.

In effect it's kind of using the new Streams2 api readable event to emulate the behaviour of the old data event. Although they should both have the same behaviour I think it makes more sense to merge this PR and revert back to data. It's much more readable, and more clearly shows the intentions of this code, as demonstrated by the confusion in this PR and the related issue. 😆

Up to you guys :)

[sindresorhus]

I guess, but I don't want to take the chance. Not worth potential breakage. Too many modules depend on this one. The current version should also be slightly faster as event emitting is slower than reading from a function, and the version in master uses a lot less events.