tokio-rs
Modifying the read request size of NamedPipe
I've been running into some performance issues reading intermittent byte streams from serial ports on windows. I have detailed the exact issue here:
https://github.com/berkowski/tokio-serial/issues/55
I can fix the performance issue (for my use-case) by modiyfing named_pipe.rs, to force read requests of only 1-byte. This seems to work well, and emulates the behavior of PuTTy.
Is it possible to modify the read request size in some way that doesn't require modifying the library source? This would allow mio-serial and tokio-serial to nicely expose the same feature, which could lead to some serious performance improvements -- particularly if the end application is decoding packets of some fixed length.
@mlsvrts am I correct in saying that the problem here is not necessarily the buffer size, but that the read is not completed the moment data is available? Perhaps their are flags we can use to return the moment any data is available.
@Thomasdezeeuw Yes, I agree that's a correct interpretation. Actually the performance would probably be better that way as well; in the case of USB to Serial adapters, for instance, I think you could receive entire blocks of data at the same time.
I am running up against this issue as well. I am trying to reasonably timestamp messages coming over a serial port, but with the current situation a whole buffer of messages comes in about once every half a second due to the buffering happening in mio. I think it would be an easy fix to just change the value to 1 to meet the expectations of the API while we wait for a more optimal solution. I am able to get something working using the synchronous serialport crate, but not with async currently due to this. For others, as a workaround I recommend switching to synchronous APIs and spawning a blocking thread for them. Make sure your BufReader has only 1 byte capacity or it wont work.
@vadixidav, @mlsvrts would a NamedPipe::set_buffer_size function, changing the buffer size used in https://github.com/tokio-rs/mio/blob/c9e33691034be4df491fed7b24b5eeb4d20f8d7d/src/sys/windows/named_pipe.rs#L806, fix this issue?
@Thomasdezeeuw Yes, I think that's the most straightforward solution; mio-serial and other libraries should be able to use that to control the buffering characteristics for read requests. In the default case, they can set the value to 1, and async applications will be notified whenever a new byte is ready.
I think dynamic modification also allows a common pattern where an application might read a header of some fixed length, and then read a body of length indicated by the header.