de-vri-es
commented
1 month ago Hey!
As an intersting point: serial2 uses a pretty similar mechanism for timeouts as tokio. To be specific, on unix it uses a select call and on Windows it uses "overlapped IO". The big difference is that with serial2, there will be one select call per serial port (and on Windows no completion handler). So it will still block your thread when you read or write.
I personally don't think 100 threads is that much these days, but I think it is enough that asynchronous I/O will provide some real performance benefits. But if those are important enough or not, I don't know. I'm afraid I can't be more precise than that, because the real-world performance is going to depend on a lot of things.
I can tell you that normally, having something async will "bleed" through to your entire program. In order to call async code, you must be in async context. And if you plan on using traits a lot, the result may not be the most comfortable (async functions in traits are still cumbersome to work with, in my opinion).
You can connect sync and async code by using channels to communicate. For example, the channels provided by tokio have both async and sync functions: tokio::sync::mpsc::Sender::send and tokio::sync::mpsc::Sender::blocking_send.
jerrywrice
First, thanks for both the 'serial2-rs' and 'serial2-tokio-rs' crates you (and your colleagues) have published - excellent work!
I'm developing a rust crate library that provides support for a well-established standard industrial automation protocol (SEMI). I'm presently considering if it is beneficial to use serial2-tokio-rs (as opposed to serial2-rs) for my RS-232 support. I'm unclear if serial2-tokio-rs is actually the best choice because my intent is to publish (only) a 'normal' sync public library API. I'm only providing a sync API since rust has not yet experienced serious adoption (trivial at most?) in the chip industrial automation space, so most developers using this library will likely be new rust developers. It will be highly disappointing (to say the least!) if I publish an async API and only then find that most or many industrial developers reject the rust async interface (and thus the library) due to a perceived steep learning curve, or are put off by the debugging challenges which exist for rust async code when using the more popular rust IDEs (this is mentioned on-line in multiple blogs/postings). I've in-fact encountered this myself while recently experimenting with async rust code while using VSCode with rust-analyzer extension enabled. I verified that the debugging problems actually cleared up once I eliminated the 'async' macro from my 'async fn main()' source line. This code in-fact worked as expected if I ran the compiled binary directly from the terminal outside VSCode. Furthermore, the code wasn't even using other async features, but simply had the 'async' macro and keyword present with my main() function's source file.
On the other hand, my interest in considering 'serial2-tokio-rs' rather than 'serial2-rs' is because this standard industrial protocol defines/requires several user configurable sub-second time-out settings per serial port connection. While the minimum value of one of these spec listed time-outs is 100 ms, with a granularity increment of 100 ms. While this doesn't sound overly challenging, some of these spec listed per 'port' time-outs are inter-related, and must be implemented with accurate timing with respect to each other so the protocol functions reliably regarding error recovery. Additionally, the current goal for my library is to support up to one-hundred (100) simultaneously active serial port connections. Therefore I'm considering if serial2-tokio-rs is better suited for this than serial2-rs, based on my understanding of the relative ease of implementing protocol 'read' time-outs using the available async specific select statement, as well as reducing thread usage via async. Regarding my background with rust async, I've not previously developed or used it (I've only recently looked into it). I therefore don't have high confidence in my ability to properly assess whether providing a synchronous high-level API that internally utilizes async library I/O code, is a good idea. I'm also concerned about undertaking a time-consuming 'bench marking' experiment phase, since I might reach erroneous conclusions due to my lack of experience with rust async. I've read some articles and technical information which indicates layering rust sync on top of rust async is problematic, while others dispute this. I'm certainly willing to invest time to carefully learn rust async programming, but I'm not clear if it's a good investment of my development time for this specific project.
My main questions are whether using async serial2-tokio-rs library rather than serial2-rs would be problematic:
Your thoughts or feedback will be very welcome? Thanks in advance for any insight.
+++Clarification: My library is NOT be required to run on an embedded 'no_std' supported computer platform. While embedded would be nice, practically all implementations of this standard automation protocol currently run on Windows or full Linux platforms (systems). In the future I can consider adding a more constrained 'no_std' embedded feature to this current development, or possibly a totally separate new crate (not important now).