1berry/nodejs
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

doc: warn against streaming from character devices

Browse Source 
charcter device streaming works just like any other streams, but hangs
on the close callsite due to the worker thread being blocked on the read
and main thread waiting for any async event that may not occur.

Document this behavior and suggest a potential workaround.

Fixes: https://github.com/nodejs/node/issues/15439
PR-URL: https://github.com/nodejs/node/pull/21212

Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
This commit is contained in:
Gireesh Punathil 2018-06-08 10:23:25 -04:00
parent 08aad66411
commit 66e6d7835e
1 changed files with 20 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
doc/api/fs.md
View File

@ -1464,6 +1464,26 @@ the specified file descriptor. This means that no `'open'` event will be
emitted. `fd` should be blocking; non-blocking `fd`s should be passed to
[`net.Socket`][].
The blocking `fd`, if pointing to a character device (such as keyboard or
sound card) can potentially block the main thread on stream close. This is
because these devices do not produce EOF character as part of their data
flow cycle, and thereby exemplify endless streams. As a result, they do not
respond to `stream.close()`. A workaround is to close the stream first
using `stream.close()` and then push a random character into the stream, and
issue a single read. This unblocks the reader thread, leads to the completion
of the data flow cycle, and the actual closing of the stream.
```js
const fs = require('fs');
// Create a stream from some character device.
const stream = fs.createReadStream('/dev/input/event0');
setTimeout(() => {
stream.close(); // This does not close the stream.
stream.push(null);
stream.read(0); // Pushing a null and reading leads to close.
}, 100);
```
If `autoClose` is false, then the file descriptor won't be closed, even if
there's an error. It is the application's responsibility to close it and make
sure there's no file descriptor leak. If `autoClose` is set to true (default