fix: infinite recursion in unix-read #164
Conversation
|
As I understand, this is an implementation of pulling logic to wait until there is a data to grub. Endless loop is better thou. |
|
Yet, a zero-sized read indicates end of file, or in this case, disconnect of the device. So even if you refactor to a "loop", and add some delays, you will not be able to detect the disconnect. I think this was designed with devices in mind, that don't support hot plugging. But then again, those should never give you zero sized reads... |
|
On linux, after disconnect the file will just disappear. But while connection is established and no data is receiving, there will be just an empty file with 0 bytes. In this case recursion will go as deep as you have available memory and crush your app, unless you receive some data. |
|
Where did you solve it? In this case, this would be in violation of the documentation, as cited in my original post. What exactly are the exit conditions you use? What kind of serial port shows this behaviour? |
|
I fixed it in my personal project, by pre-building library and replacing this file with fixed one. I can create PR with my solution, so you can take a look. |
|
I believe it is quite common with non blocking reads to get 0 bytes. Also currently the contract of the binding is to always return at least 1 byte. Your runaway process in #162 is a different issue. We might not be getting an error when we should be. |
Fixes #162
According to man 2 read:
According to node fs:
If I understand this correctly (maybe there are some edge cases in the serialport read API?), we should never recurse if read returns zero.
Also, the @serialport/stream package (correctly) contains checks for zero-sized reads here, which could never be the case if we keep recursing on zero.
I had the problems described in #162 with a USB serial port (/dev/ttyUSB0). When I unplugged it during runtime, my program went into this infinite recursion and crashed due to memory. With this fix, it worked as expected.