Set SO_REUSEADDR
again for wasmtime serve
on unix
#8738
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This effectively reverts #7863 which was a misunderstanding on my part about
SO_REUSEADDR
. I think I mixed it up withSO_REUSEPORT
. WithoutSO_REUSEADDR
it's possible to have this happen:wasmtime serve
sessionnc
Due to the active TCP connection at the time the server was killed the socket/address is in the
TIME_WAIT
state which apparently prevents rebinding the port until the OS has a chance to clean up everything. SettingSO_REUSEADDR
enables rebinding the address quickly.Now in #7863 that was trying to fix #7852 which said that it was possible to have multiple
wasmtime serve
instances binding the same port. That can lead to confusion and is generally something we don't want. That being said #7863 didn't actually change anything on either macOS or Unix, although it did fix the issue on Windows. Turns out the fix for both these issues was to only turn offSO_REUSEADDR
on Windows, but leave it on for Unix.This PR additionally adds two new tests, both for rebinding an in-use port quickly and additionally ensuring the same port can't be listened to twice.