Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upTurn 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+ |
|
|
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
|
|
|
@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
|
|
|
@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
|
|
|
@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
|
|
|
@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
|
|
|
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
|
|
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 #29.
|
Forgot to commit changes. r? @jdm |
|
@bors-servo: r+ |
|
|
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
|
|
0146ae7
into
servo:master
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 -->
pcwalton commentedJan 22, 2016
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_LINGERcauses
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