Infinite write loop on device disconnect

[arikwex]

Hi folks,

I have a serial device that, when connected, does two things:

1. Adds a device FD with fixed path (e.g. /dev/serial/by-id/my-device)
2. Symlinks that FD to /dev/ttyACM0
   I can communicate with this device via node-serialport with no problems.

Now, this device can be disconnected at any time. When it is disconnected, the two file descriptors (mentioned above) vanish. If there was an ongoing write request, then the EIO_Write function in serialport_unix.cpp will indefinitely spam EBADF errors.

My current options seem to be:

1. Create a sentinel FD for node-serialport to connect to, then use something like socat to pipe the newly connected device IO to this sentinel FD.
2. Modify the EIO_Write function to terminate on EBADF errors and close the port.

Serialport best practices are not my native tongue, so any advice on this issue would be much appreciated.
Cheers and thanks,
-arikwex

[reconbot]

I suppose it would make sense to auto close and disconnect the port if we get EBADF errors on write. Right now you'll have to do that yourself. On windows there's a chance the disconnect will work automatically. On linux only sometimes detects it. We have #702 tracking the issue.

[reconbot]

Wait, did you mean to write that EIO_Write will infinitely spam the write callback with EBADF errors? Eg on a single write you keep getting the error? That's no good. It doesn't look like it should do that though as it's not being specially handed for retry.

If you meant every write afterwards will also get a EBADF then.. well yeah that would happen. This would be a work around.

port.write(data, function(err){
  if(err) { return port.close(); }
});

Disconnect isn't slated for 4.0 unfortunately, but the latest beta ([email protected]) has better write behavior as it will only call your callback once for each write.

[reconbot]

I'm going to close this due to age, as part of disconnect handling I agree we should be detecting EBADF on writes. That's not a feature we currently have. If I have your problem wrong I'm happy to reopen.