-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
loop_fn with poll_peek randomly hangs despite data available #965
Comments
Some observations:
|
Returning pure Use
BTW I don't think |
@sopium Thank you for your input. I could also consume the buffer to avoid the poll_peek, but then I have difficulties calling the copy operation below. I see no option to combine my read data with the rest to make the io::copy work. Reagarding poll_peek: it returns the same data means it does not consume it, but there could be more data available, thus the buffer will get filled more. Regardless of the design flaws in my code: I think that the poll_peek not seeing data is still a bug |
You should be able to
Yeah, it's true that the buffer will get filled more. But
You have to return |
That was my plan, but I will now try to do the The code above was just a prototype. But in the example, the poll_peek never returned a single |
I believe that @sopium has provided the answer, the error lies in incorrect usage of the Tokio APIs. As such, closing. If this is a misinterpretation, please comment and I can reopen. |
I don't see how that could happen.
https://github.com/tokio-rs/tokio/blob/master/tokio-tcp/src/stream.rs#L328-L339
If you could provide a minimal repro, i can take a closer look. Something I
can easily run.
…On Mon, Jul 15, 2019 at 12:24 AM Georg Müller ***@***.***> wrote:
Well, even if I may have solved it differently, I still think it is a bug.
The poll_peek never returns, even if there is data available (where it
should return)
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#965?email_source=notifications&email_token=AAABQJHWUHLIUUVT4JP24S3P7QQZPA5CNFSM4G4W4PCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ44WOY#issuecomment-511298363>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAABQJCHPNCEMQPNVBN7XH3P7QQZPANCNFSM4G4W4PCA>
.
|
Sorry, I missed something and deleted my comment minutes after posting it, but the mail was already out. Closing this is okay. The other problem I have seems unrelated. When woken up once, I cannot re-peek the data if there is not enough data (say: if n < 10 return Ok(Async::NotReady)) In this case the peek is not triggered again. |
Version
tokio 0.1.16
$ cargo tree | grep tokio | grep -v '(*)' | grep -o tokio.*
tokio v0.1.16
tokio-codec v0.1.1
tokio-io v0.1.12
tokio-current-thread v0.1.5
tokio-executor v0.1.6
tokio-fs v0.1.6
tokio-threadpool v0.1.12
tokio-reactor v0.1.9
tokio-sync v0.1.3
tokio-tcp v0.1.3
tokio-timer v0.2.10
tokio-udp v0.1.3
tokio-uds v0.2.5
Platform
Linux nb-georg 4.20.11-200.fc29.x86_64 #1 SMP Wed Feb 20 15:56:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Description
I am trying to develop a library for an sniproxy, forwarding TLS tcp streams to a target, but peeking into the stream to get the SNI field to chose the target by a manager. I have the following gist which is broken down to forward everything to a local https server after the first peek succeeded:
https://gist.github.com/georgmu/5cc90160a8b2efb1c560f017409b0527
This works from time to time, but randomly hangs. If it hangs, the CPU runs at 100% and I uncomment the "Not ready", this will spam the console.
The hangs happen more often in release mode than in debug mode.
Test environment: start a local https server listening on port 8443 (or change the IP/Port in the forward function (not in main() - I was not able to forward it into the forward function without borrow checker problems)
Then run
curl https://localhost:5555/
oropenssl s_client -connect localhost:5555
The data is threre. I can check that in the socket statistics:
There are 303 bytes available for sniproxy.
Looking at strace, the function does no syscalls to receive the data, just looping in userspace. But as mentioned above, the closure which calls poll_peek() gets called.
Here is a backtrace of a hung process:
The text was updated successfully, but these errors were encountered: