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

fix: drop mutex guard when DuplexStream I/O op is pending #8

Merged
merged 2 commits into from
Oct 24, 2024

Conversation

SteveLauC
Copy link
Owner

What does this PR do

  1. Fixes the issue described in DuplexStream pending I/O keeps holding the Mutex #7, closes DuplexStream pending I/O keeps holding the Mutex #7.
  2. Replaces async_lock::Mutex with std::sync::Mutex because:
    1. We have ensured that a lock guard will be held across an await point.
    2. Using blocking Mutex in a single-threaded runtime like Monoio won't harm performance, as only 1 async task can executed at any time.
    3. Using async Mutex forces us to handle async operations in Drop, I used futures::executor::block_on() before this PR, but it is dangerous and can lead to deadlock with careless mistakes.
  3. 2 tests are added to ensure DuplexStream pending I/O keeps holding the Mutex #7 won't happen again.

@SteveLauC SteveLauC merged commit b2b333b into main Oct 24, 2024
2 checks passed
@SteveLauC SteveLauC deleted the fix/deadlock_duplexstream branch October 24, 2024 08:50
// drop the Mutex guard or it could deadlock
// https://github.com/SteveLauC/monoio-duplex/issues/7
drop($guard);
std::future::pending().await
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Future polls to this future will always return Pending due to this line, the state of this future has been changed, which should never be done!

SteveLauC added a commit to infinilabs/rskafka-monoio that referenced this pull request Oct 28, 2024
### What does this PR do

This PR is our first step that changes the runtime used by rskafka from Tokio to Monoio, currently, the following items are done:

* source code can be built

* unit tests are all passed

  > The unit tests of `Messenger` have been removed bc they need `tokio::io::DuplexStream`. I tried to port its implementation but failed because Monoio's I/O traits require the implementation of `SimplexStream` to support concurrent read/write[1], `Tokio::io::SimplexStream` is basically a `bytes::BytesMut`, so it cannot support that.
  >
  > They can be added back once we have a working version of [monoio-duplex](https://github.com/SteveLauC/monoio-duplex)



The things that do not work:



1. TLS support
2. SOCKS5 proxy
3. Integration tests
4. Fuzzy tests
5. Benchmark



[1]: `DuplexStream` basically contains 2 `SimplexStream`, one for read, the other for write. If `SimplexStream` does not support concurrent read/write, then it needs to be wrapped in a `Mutex`, then you will have [this issue](SteveLauC/monoio-duplex#7), which is unsolvable, the patch sent in [this PR](SteveLauC/monoio-duplex#8 (comment)) won't work because it changes the state of future, which should never be done.
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 this pull request may close these issues.

DuplexStream pending I/O keeps holding the Mutex
1 participant