Closed DanielJoyce closed 9 months ago
Basically, if there is data to read, it returns immediately. If there is no data, it waits until the configured timeout has passed. If there is data to write, it writes immediately. If the timeout passes when writing, it returns immediately.
This matches the expected behavior which for many developers is POSIX style. The more advanced settings could be exposed as additional config items in the windows config.
Please note, I have no way of testing this. I am just applying the changes I've seen in other serial port packages to this one.
Thanks! On a first glance and from the docs, it looks good. I'll do some tests on a Windows machine too. I just need to get my hands one one first :p
Yeah, there is about zero info on the write side on what the write timeout should be.
Adding this for notes
Will dig in here and see how they do it since a lot of windows users coming from python to rust are getting tripped up and it seems PySerial sets the timeout behavior to be more posix style.
You may already be familiar with this, but the key info on the Windows DCB timeout settings and associated behavior is found at link https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddser/ns-ntddser-_serial_timeouts
In my experience as an IoT/instrument software developer, the following excerpt is what I use in practice most often =>
If both ReadIntervalTimeout and ReadTotalTimeoutMultiplier are set to MAXULONG, and ReadTotalTimeoutConstant is set to a value greater than zero and less than MAXULONG, a read request behaves as follows:
If there are any bytes in the serial port's input buffer, the read request completes immediately with the bytes that are in the buffer and returns the STATUS_SUCCESS status code.
If there are no bytes in the input buffer, the serial port waits until a byte arrives, and then immediately completes the read request with the one byte of data and returns the STATUS_SUCCESS status code.
If no bytes arrive within the time specified by ReadTotalTimeoutConstant, the read request times out, sets the Information field of the I/O status block to zero, and returns the STATUS_TIMEOUT status code.**
Closing this in favor of #15: that one sets a 3 second default timeout and it sets WriteTotalTimeoutMultiplier
to 0
instead of u32::MAX
.
It also sets the same timeout by default for the Unix implementation.
Thanks for all the discussion and suggestions!
Matches the normal developer expectations around POSIX style timeouts
See ticket #7 for discussion