Stop relying on synchronous reads from STDIN #1142
Comments
RomainMuller
added
bug
When using node >= 13.2, attempts to synchronously read from STDIN often result in `EAGAIN` being raised. This is due to the STDIN file descriptor being opened with `O_NONBLOCK`. This introduces a temporary workaround that catches the EAGAIN exception and re-attempts reading from STDIN "immediately". While this is not the ideal solution, it can be done right away and appears to have minimal impact on the overall performance of applications. A longer term fix is to move away from synchronous IO operations, but this is a significantly mroe involved fix and migth be a while before this can be delivered. The long term solution is tracked in #1142. Related to aws/aws-cdk#5187
|
I don't think it will be possible to move away from synchronous reads since you need to invoke host callbacks during synchronous javascript function calls, so you need to block the javascript execution. |
|
Can you also provide a reference to the node.js documentation that says that stdin is opened with O_NONBLOCK? From joyent/libuv@1988f5e is seems like it's actually opened without O_NONBLOCK |
When using node >= 13.2, attempts to synchronously read from STDIN often result in `EAGAIN` being raised. This is due to the STDIN file descriptor being opened with `O_NONBLOCK`. This introduces a temporary workaround that catches the EAGAIN exception and re-attempts reading from STDIN "immediately". While this is not the ideal solution, it can be done right away and appears to have minimal impact on the overall performance of applications. A longer term fix is to move away from synchronous IO operations, but this is a significantly mroe involved fix and migth be a while before this can be delivered. The long term solution is tracked in #1142. Related to aws/aws-cdk#5187
…1143) When using node >= 13.2, attempts to synchronously read from STDIN often result in `EAGAIN` being raised. This is due to the STDIN file descriptor being opened with `O_NONBLOCK`. This introduces a temporary workaround that catches the EAGAIN exception and re-attempts reading from STDIN "immediately". While this is not the ideal solution, it can be done right away and appears to have minimal impact on the overall performance of applications. A longer term fix is to move away from synchronous IO operations, but this is a significantly mroe involved fix and migth be a while before this can be delivered. The long term solution is tracked in #1142. Related to aws/aws-cdk#5187
The code you are pointing at is the code that initializes the STDIN/OUT for child processes, which was introduced around nodejs/node-v0.x-archive#3994, where people very specifically call out that, unlike |
|
That being said, I think you're correct about it not being possible to make this process synchronous (or it'd require the application's code performs NO asynchronous operation ever). |
|
This issue has not received any attention in 2 years. If you want to keep this issue open, please leave a comment below and auto-close will be canceled. |
github-actions
bot
added
closing-soon
🐛 Bug Report
Affected Languages
TypeScriptorJavascriptPythonJavaC#,F#, ...)What is the problem?
nodeopens it's STDIN file descriptor inO_NONBLOCKmode, making attempts to synchronously read unsafe. Starting with node13.2, there has been a significant increase in the incidence of hitting EAGAIN in this process. Synchronous mitigations are tacky at best, and the proper way to fix is to move away from synchronous IO.See aws/aws-cdk#5187
The text was updated successfully, but these errors were encountered: