Skip to content
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

Merged
merged 1 commit into from
Jan 25, 2016

Conversation

pcwalton
Copy link
Contributor

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

@jdm
Copy link
Member

jdm commented Jan 22, 2016

This means that the socket hangs around for 30s before its data becomes unavailable like before, right?

@pcwalton
Copy link
Contributor Author

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.

@jdm
Copy link
Member

jdm commented Jan 22, 2016

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.

@jdm
Copy link
Member

jdm commented Jan 22, 2016

@bors-servo: r+

@bors-servo
Copy link
Contributor

📌 Commit 153f474 has been approved by jdm

@bors-servo
Copy link
Contributor

⌛ Testing commit 153f474 with merge db5280a...

bors-servo pushed a commit that referenced this pull request Jan 22, 2016
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
Copy link
Contributor

💔 Test failed - travis

@jdm
Copy link
Member

jdm commented Jan 22, 2016

@bors-servo: retry

@bors-servo
Copy link
Contributor

⌛ Testing commit 153f474 with merge 619a420...

bors-servo pushed a commit that referenced this pull request Jan 22, 2016
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
Copy link
Contributor

💔 Test failed - travis

@jdm
Copy link
Member

jdm commented Jan 22, 2016

@bors-servo: retry

@bors-servo
Copy link
Contributor

⌛ Testing commit 153f474 with merge 28dce6a...

bors-servo pushed a commit that referenced this pull request Jan 22, 2016
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
Copy link
Contributor

💔 Test failed - travis

@jdm
Copy link
Member

jdm commented Jan 22, 2016

@bors-servo: retry

@bors-servo
Copy link
Contributor

⌛ Testing commit 153f474 with merge ea0eb7e...

bors-servo pushed a commit that referenced this pull request Jan 22, 2016
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
Copy link
Contributor

💔 Test failed - travis

@jdm
Copy link
Member

jdm commented Jan 23, 2016

@bors-servo: retry

@bors-servo
Copy link
Contributor

⌛ Testing commit 153f474 with merge b2bd35f...

bors-servo pushed a commit that referenced this pull request Jan 23, 2016
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
Copy link
Contributor

💔 Test failed - travis

@jdm
Copy link
Member

jdm commented Jan 23, 2016

@jdm
Copy link
Member

jdm commented Jan 25, 2016

@bors-servo: retry

@bors-servo
Copy link
Contributor

⌛ Testing commit 153f474 with merge c5bec7a...

bors-servo pushed a commit that referenced this pull request Jan 25, 2016
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
Copy link
Contributor

💔 Test failed - travis

@jdm
Copy link
Member

jdm commented Jan 25, 2016

platform/linux/mod.rs:499:18: 499:24 error: `linger` does not name a structure [E0422]

platform/linux/mod.rs:499     let linger = linger {

                                           ^~~~~~

platform/linux/mod.rs:499:18: 499:24 help: run `rustc --explain E0422` to see a detailed explanation

platform/linux/mod.rs:504:32: 504:42 error: unresolved name `SOL_SOCKET` [E0425]

platform/linux/mod.rs:504                                SOL_SOCKET,

                                                         ^~~~~~~~~~

platform/linux/mod.rs:504:32: 504:42 help: run `rustc --explain E0425` to see a detailed explanation

platform/linux/mod.rs:506:50: 506:56 error: use of undeclared type name `linger` [E0412]

platform/linux/mod.rs:506                                &linger as *const linger as *const c_void,

                                                                           ^~~~~~

platform/linux/mod.rs:506:50: 506:56 help: run `rustc --explain E0412` to see a detailed explanation

platform/linux/mod.rs:507:47: 507:53 error: use of undeclared type name `linger` [E0412]

platform/linux/mod.rs:507                                mem::size_of::<linger>() as socklen_t);

                                                                        ^~~~~~

platform/linux/mod.rs:507:47: 507:53 help: run `rustc --explain E0412` to see a detailed explanation

platform/linux/mod.rs:499:18: 499:24 error: `linger` does not name a structure [E0422]

platform/linux/mod.rs:499     let linger = linger {

                                           ^~~~~~

platform/linux/mod.rs:499:18: 499:24 help: run `rustc --explain E0422` to see a detailed explanation

platform/linux/mod.rs:504:32: 504:42 error: unresolved name `SOL_SOCKET` [E0425]

platform/linux/mod.rs:504                                SOL_SOCKET,

                                                         ^~~~~~~~~~

platform/linux/mod.rs:504:32: 504:42 help: run `rustc --explain E0425` to see a detailed explanation

platform/linux/mod.rs:506:50: 506:56 error: use of undeclared type name `linger` [E0412]

platform/linux/mod.rs:506                                &linger as *const linger as *const c_void,

                                                                           ^~~~~~

platform/linux/mod.rs:506:50: 506:56 help: run `rustc --explain E0412` to see a detailed explanation

platform/linux/mod.rs:507:47: 507:53 error: use of undeclared type name `linger` [E0412]

platform/linux/mod.rs:507                                mem::size_of::<linger>() as socklen_t);

                                                                        ^~~~~~

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.
@pcwalton
Copy link
Contributor Author

Forgot to commit changes. r? @jdm

@jdm
Copy link
Member

jdm commented Jan 25, 2016

@bors-servo: r+

@bors-servo
Copy link
Contributor

📌 Commit 0146ae7 has been approved by jdm

@bors-servo
Copy link
Contributor

⌛ Testing commit 0146ae7 with merge 3a95bec...

bors-servo pushed a commit that referenced this pull request Jan 25, 2016
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
Copy link
Contributor

☀️ Test successful - travis

@bors-servo bors-servo merged commit 0146ae7 into servo:master Jan 25, 2016
dlrobertson added a commit to dlrobertson/ipc-channel that referenced this pull request Mar 28, 2016
Add test for servo#30. Test that data can be retrieved from the receiver
after the sender has been dropped.
dlrobertson added a commit to dlrobertson/ipc-channel that referenced this pull request Mar 28, 2016
Add test for servo#30. Test that data can be retrieved from the receiver
after the sender has been dropped.
bors-servo pushed a commit that referenced this pull request Mar 29, 2016
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 -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Intermittent "Connection reset by peer" for in-process channel in a recv() with a queued message but no sender
3 participants