-
Notifications
You must be signed in to change notification settings - Fork 132
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
Turn on SO_LINGER
for client communication sockets.
#30
Conversation
This means that the socket hangs around for 30s before its data becomes unavailable like before, right? |
It's 30 seconds or whenever the receiver has read all the data, whichever comes first. The 30 second timeout should hopefully never happen in practice--it would only happen if the receiver leaked its receiving end for some reason. |
Well, it's not hard for me to imagine cases where the receiver is not sitting waiting synchronously and is occasionally polling (the equivalent of setTimeout, basically), but this seems like it should be an improvement over the status quo. |
@bors-servo: r+ |
📌 Commit 153f474 has been approved by |
Turn on `SO_LINGER` for client communication sockets. This reduces the probability that the receiver receives errors when we close our end of the socket with data remaining. There is deadlock potential with this patch, because turning on `SO_LINGER` causes `close()` to block until the receiver has received all the data. If deadlocks happen, a workaround will be to close sockets in a separate thread. This is ugly and slow, so I don't want to do that unless we need to. Might fix #29. r? @jdm
💔 Test failed - travis |
@bors-servo: retry |
Turn on `SO_LINGER` for client communication sockets. This reduces the probability that the receiver receives errors when we close our end of the socket with data remaining. There is deadlock potential with this patch, because turning on `SO_LINGER` causes `close()` to block until the receiver has received all the data. If deadlocks happen, a workaround will be to close sockets in a separate thread. This is ugly and slow, so I don't want to do that unless we need to. Might fix #29. r? @jdm
💔 Test failed - travis |
@bors-servo: retry |
Turn on `SO_LINGER` for client communication sockets. This reduces the probability that the receiver receives errors when we close our end of the socket with data remaining. There is deadlock potential with this patch, because turning on `SO_LINGER` causes `close()` to block until the receiver has received all the data. If deadlocks happen, a workaround will be to close sockets in a separate thread. This is ugly and slow, so I don't want to do that unless we need to. Might fix #29. r? @jdm
💔 Test failed - travis |
@bors-servo: retry |
Turn on `SO_LINGER` for client communication sockets. This reduces the probability that the receiver receives errors when we close our end of the socket with data remaining. There is deadlock potential with this patch, because turning on `SO_LINGER` causes `close()` to block until the receiver has received all the data. If deadlocks happen, a workaround will be to close sockets in a separate thread. This is ugly and slow, so I don't want to do that unless we need to. Might fix #29. r? @jdm
💔 Test failed - travis |
@bors-servo: retry |
Turn on `SO_LINGER` for client communication sockets. This reduces the probability that the receiver receives errors when we close our end of the socket with data remaining. There is deadlock potential with this patch, because turning on `SO_LINGER` causes `close()` to block until the receiver has received all the data. If deadlocks happen, a workaround will be to close sockets in a separate thread. This is ugly and slow, so I don't want to do that unless we need to. Might fix #29. r? @jdm
💔 Test failed - travis |
Will need to wait for either https://github.com/Manishearth/rust-clippy/issues/576 or serde-deprecated/aster#63. |
@bors-servo: retry |
Turn on `SO_LINGER` for client communication sockets. This reduces the probability that the receiver receives errors when we close our end of the socket with data remaining. There is deadlock potential with this patch, because turning on `SO_LINGER` causes `close()` to block until the receiver has received all the data. If deadlocks happen, a workaround will be to close sockets in a separate thread. This is ugly and slow, so I don't want to do that unless we need to. Might fix #29. r? @jdm
💔 Test failed - travis |
Incomplete changes? |
This reduces the probability that the receiver receives errors when we close our end of the socket with data remaining. There is deadlock potential with this patch, because turning on `SO_LINGER` causes `close()` to block until the receiver has received all the data. If deadlocks happen, a workaround will be to close sockets in a separate thread. This is ugly and slow, so I don't want to do that unless we need to. Might fix servo#29.
Forgot to commit changes. r? @jdm |
@bors-servo: r+ |
📌 Commit 0146ae7 has been approved by |
Turn on `SO_LINGER` for client communication sockets. This reduces the probability that the receiver receives errors when we close our end of the socket with data remaining. There is deadlock potential with this patch, because turning on `SO_LINGER` causes `close()` to block until the receiver has received all the data. If deadlocks happen, a workaround will be to close sockets in a separate thread. This is ugly and slow, so I don't want to do that unless we need to. Might fix #29. r? @jdm
☀️ Test successful - travis |
Add test for servo#30. Test that data can be retrieved from the receiver after the sender has been dropped.
Add test for servo#30. Test that data can be retrieved from the receiver after the sender has been dropped.
Test: data is recv-able after sender is dropped Add test for #30. Test that data can be retrieved from the receiver after the sender has been dropped. Fixes: #33 <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/ipc-channel/58) <!-- Reviewable:end -->
This reduces the probability that the receiver receives errors when we
close our end of the socket with data remaining.
There is deadlock potential with this patch, because turning on
SO_LINGER
causes
close()
to block until the receiver has received all the data. Ifdeadlocks happen, a workaround will be to close sockets in a separate thread.
This is ugly and slow, so I don't want to do that unless we need to.
Might fix #29.
r? @jdm