Async split of Reader and Writer for a SerialPort

code review
1

I have a use case, where I need a serial port in a transmitter and a receiver thread (i.e. tokio task).
The transmitter part shall just send via the serial port and the receiver shall just receive from it.

Hence, I burnt last midnight's oil and came up with this:

Disclaimer: Parts of the code and the docs are AI-generated.

I'd like to have feedback on

  • Code and documentation quality.
  • Soundness of the implementation.
  • Usefulness - Did I reinvent the wheel?

PS: This post was entirely hand-written, though. :wink:

2

message.rs -- could you possibly move this into lib.rs? im not a network programmer but i feel like message.rs is a bit redundant unless you were/are willing to expand on it

reader.rs & others -- function naming and inner is more than enough in this case but the documentation is a nice touch. maybe you could fill out a bit more in reader.rs's Reader because it did take me a few takes to understand copy_buffered_or_complete_empty_read

take my comments with a grain of salt however.

3

I thought about this, but I don't think that this is a good idea.
For me, the main module file shall mainly aggregate the exports of submodules and re-export appropriate items to provide a lucid API of that module.

The main module, thus, for me shall contain the main stuff, which the API's i.e. the library's user is interested in.

Message is totally an internal implementation detail which is not exported from the library.
The message is transferred between the Worker actor and the Reader and Writer handles for communication. This should be completely opaque to the user, as they just have a reader they can use to read from the serial port and a writer to write to it (and somewhere in a task, the worker is doing its job). The messages exchanged thus, shall not be prominently visible in the crate's root.