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

net_tcp doesn't use SO_REUSEADDR #3597

Closed
jesse99 opened this Issue Sep 26, 2012 · 6 comments

Comments

Projects
None yet
7 participants
@jesse99
Contributor

jesse99 commented Sep 26, 2012

which is really annoying.

@catamorphism

This comment has been minimized.

Show comment
Hide comment
@catamorphism

catamorphism May 23, 2013

Contributor

Nominating for milestone 3, feature-complete

Contributor

catamorphism commented May 23, 2013

Nominating for milestone 3, feature-complete

@bblum

This comment has been minimized.

Show comment
Hide comment
@bblum

bblum Jun 10, 2013

Contributor

libextra::timer and libextra::net_tcp are deprecated pending #6435. Is this still functionality that will be needed in the new implementation?

Contributor

bblum commented Jun 10, 2013

libextra::timer and libextra::net_tcp are deprecated pending #6435. Is this still functionality that will be needed in the new implementation?

@metajack

This comment has been minimized.

Show comment
Hide comment
@metajack

metajack Jun 27, 2013

Contributor

Yes. SO_REUSEADDR is very commonly used.

Contributor

metajack commented Jun 27, 2013

Yes. SO_REUSEADDR is very commonly used.

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Jun 27, 2013

Member

sounds critical for implementing server. accepted for feature complete

(did I mean to say "Servo" above? Not my area of expertise, clearly.)

Member

pnkfelix commented Jun 27, 2013

sounds critical for implementing server. accepted for feature complete

(did I mean to say "Servo" above? Not my area of expertise, clearly.)

@anasazi

This comment has been minimized.

Show comment
Hide comment
@anasazi

anasazi Sep 18, 2013

Contributor

I don't think this is relevant in the new runtime's non-blocking I/O (libuv takes care of this stuff internally).
Unless we're going to write a native I/O interface, then I think we can close this.

Contributor

anasazi commented Sep 18, 2013

I don't think this is relevant in the new runtime's non-blocking I/O (libuv takes care of this stuff internally).
Unless we're going to write a native I/O interface, then I think we can close this.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Oct 18, 2013

Member

Closing due to the libextra modules having been jettisoned and libuv handling this much differently.

Member

alexcrichton commented Oct 18, 2013

Closing due to the libextra modules having been jettisoned and libuv handling this much differently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment