Skip to content

Separate the action of starting a TCP listener from the action of waiting to accept the first incoming connection. #8689

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
anasazi opened this issue Aug 22, 2013 · 2 comments
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@anasazi
Copy link
Contributor

anasazi commented Aug 22, 2013

Currently we do not start listening on a TCP socket until we call .accept() for the first time (at which point we block until there is an incoming connection). This makes it difficult to test TCP code in a multithreaded environment since we cannot guarantee that the server is up and running before attempting to connect without having the client spin on connection attempts.

I would like to move to this alternative interface:

TcpListener.listen() consumes the TcpListener and returns a TcpAcceptor.
TcpAcceptor.accept() replicates the current behavior of TcpListener.accept() (blocks and returns a Result).
TcpAcceptor will implement Iterator and produce an infinite stream of incoming connections.
The socket will be closed when the TcpAcceptor goes out of scope.

The libuv listener takes the backlog size as a parameter. Currently, we hardcode this to 128, but we could make it a argument of TcpListener.listen() and provide a default.

@Fensteer
Copy link

Fensteer commented Nov 2, 2018

In the current version of TCP implementation, these changes have been overwritten, is it a regression ? The overwrite occurred when net2 has been merge to net.

@anasazi
Copy link
Contributor Author

anasazi commented Nov 3, 2018

You'd need to talk to the net2 folks since I haven't worked on this in years. Personally, I liked the separation rather than allow redundant .listen()s, but that's really an interface design question.

flip1995 pushed a commit to flip1995/rust that referenced this issue Apr 21, 2022
…cursion, r=llogiq

Prevent infinite (exponential) recursion in only_used_in_recursion

This simplifies the visitor code a bit and prevents checking expressions
multiple times. I still think this lint should be removed for now,
because its code isn't really tested.

Fixes rust-lang#8689

**NOTE:** Before merging this, we should talk about removing and revisiting this lint. See my comment in rust-lang#8689

changelog: prevent infinite recursion in [`only_used_in_recursion`]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
2 participants