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
Hang in tokio multi-threaded runtime #27
Comments
Hi @bin, Good find. I took a look at this and I don't think it's a deadlock, but it is clearly a race condition. I have a similar setup going in the The In looking at the network traffic I noticed that when this does repro it always happens when the client decides not to flush the socket after writing some bytes. This was just an optimization, and callers can disable it by setting the I also found an issue in the logic that decides whether to flush the socket, so I think that's the root cause. My suspicion is that it's an atomic ordering issue in the counter that determines whether to flush some bytes, which would explain why it doesn't repro on a single thread. I'll need to spend some time with loom but if that's the issue I'll get an update out hopefully this weekend. |
Yeah, that is the issue. It's not an issue of using the wrong I'll get a patch up for 4.x this weekend. |
I suspect this may be some sort of deadlock issue, as this is resolved by running in a single-threaded runtime. You will find minimum viable examples of the multi- and single-threaded behaviors at https://github.com/bin/fred_broken.git
The text was updated successfully, but these errors were encountered: