Skip to content

Why is TcpStream::connect no longer using mio::net::TcpStream::connect? #678

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

Closed
twittner opened this issue Jan 15, 2020 · 1 comment
Closed

Comments

@twittner
Copy link
Contributor

In d25dae5, the implementation of TcpStream::connect was switched from using mio's non-blocking connect to the blocking std::net::TcpStream::connect which is performed in a background thread created by spawn_blocking. May I ask why you decided to no longer use mio's non-blocking connect? It seems the background thread spawned is unaware of any future cancellation, e.g. due to timeouts, but continues to run until all SYN retries have been exhausted which may easily last a couple of minutes. This in turn can cause a high number of threads to be created in the background.

@ghost
Copy link

ghost commented Jan 21, 2020

Hmmm, that definitely looks like an oversight during the refactor. I agree with you - we should use mio's non-blocking connect. Happy to review a PR for it!

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

No branches or pull requests

1 participant