-
Notifications
You must be signed in to change notification settings - Fork 38
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
EOF caused excessive polling #33
Comments
This is an interesting question, I welcome a PR! I agree that we should have a non-local EOF, in fact it was there before
I am also interested in this, can you open an issue for it?
I am not sure if this behavior is ideal, you can try it. :)
This is reasonable, but it should be set by the user. |
I checked the master branch, it seems the necessary state is already there so I plan to move there.
Sure, I have figured out the problem. Described in #34 .
I will add this limit option first and see how it works. |
Limiting buffer size introduced a bunch of unexpected behavior (e.g. seeing a sudden increase of sendto call which are all EAGAIN). Digging into tokio to see why this happened. |
Limit buffer size only needs to be written like this connector.accept_with(io, |session| session.set_buffer_limit(BUFFER_SIZE)) There is no need to add a new option to connector. |
You are right. BTW, what git development flow would this repository use? I typically do " git commit --fixup " to patch minor errors. After approval I will rebase to master and autosquash those fixup commits. Does that conflict with your work flavor? |
No, I don't care about this. :) |
A few updates:
This means what I previously suggested, i.e. "EOF flag", "Rate limit" will not solve the problem fundamentally. I am going to try if it will be helpful to call shutdown(Read) directly when EOF is read... |
It sounds like This is unlikely to be implemented in |
yeah, I think this issue is actually reported before here in tokio: tokio-rs/tokio#449. Problem is that HUP is not never cleared once it is returned. So it is not a tokio-rustls specific problem. I need to sit down and think about how to handle this... |
Should this be fixed by tokio-rs/mio#939 ? |
Yes that's right. I am closing this ticket as well now. Thanks! |
Hi buddy, thanks for fixing issue #32. But I need your help again...
Having my program run branch 0.9-fix with some traffic, and I encountered two additional problems:
Basically, it just repeats "sendto -> EAGAIN, recvfrom -> 0" within the tokio::io::copy context, inside AsyncWrite::poll_flush method. This eats a lot of CPU time at busy time.
My speculation about the problem is:
One myth to resolve is the 2nd point. Tokio is using the epoll edge trigger mode, so readable events should be notified only once, before consuming the socket read buffer. However, I am not sure if this is the case for EOF. TcpStream does not show such repeat EOF trigger behavior though. So there might be some fancy stuff inside tokio that does the magic.
This is also a non-deterministic behavior. I attached a similar tar ball to reproduce with a multi-client program together with cloned tokio-rustls code. Can see it when run for a few times. Anyway, I guess a short term solution is to make EOF flag live across read/write calls, instead of using a local EOF flag. This way at least read is not polled more than once after shutdown. Still pondering if this can stop the future being polled again and again though...
Besides, the issue would raise the discussion about whether do write call in read again. My concern is that so far the implementation can make read hard to proceed when write pressure is heavy. But frankly speaking I don't have a clue about what is right or best for TLS communication so I am just discussing possibilities:
Anyway I am throwing a lot of content here, so hopefully it does not get you distracted. To completely address the issue I brought here I think the EOF thing needs to be fixed and write should be rate limited. I am also happy to get some PR up, you call it :)
Thanks for your time to read the long post!
tokio-issue-new.tar.gz
The text was updated successfully, but these errors were encountered: