Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider impl Sync for SerialPort trait #232

Open
unlimitedsola opened this issue Dec 11, 2024 · 0 comments · May be fixed by #233
Open

Consider impl Sync for SerialPort trait #232

unlimitedsola opened this issue Dec 11, 2024 · 0 comments · May be fixed by #233

Comments

@unlimitedsola
Copy link

unlimitedsola commented Dec 11, 2024

I would like to propose implementing the Sync trait for the SerialPort trait. The primary blocker for this seems like COMPort does not automatically implement Sync due to the HANDLE type using a raw pointer. TTYPort already implements Sync because it uses RawFd which is simply a primitive type.

Upon investigation, I found the Rust standard library contains the following statement about Windows HANDLE types:

// The Windows [`HANDLE`] type may be transferred across and shared between
// thread boundaries (despite containing a `*mut void`, which in general isn't
// `Send` or `Sync`).
//
// [`HANDLE`]: std::os::windows::raw::HANDLE
#[stable(feature = "io_safety", since = "1.63.0")]
unsafe impl Send for OwnedHandle {}
// ...
#[stable(feature = "io_safety", since = "1.63.0")]
unsafe impl Sync for OwnedHandle {}

Maybe we could do the same for the COMPort type by implementing the Sync trait similarly. This would allow SerialPort to also implement Sync, enabling usage in multi-threaded contexts. I believe this is sound because IO-related operations still require exclusive access to &mut Self to perform.

@unlimitedsola unlimitedsola linked a pull request Dec 12, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant