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
Collaborator

pcwalton commented Jan 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_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
Collaborator Author

pcwalton commented Jan 22, 2016

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
Copy link
Contributor

bors-servo commented Jan 22, 2016

📌 Commit 153f474 has been approved by jdm

@bors-servo
Copy link
Contributor

bors-servo commented Jan 22, 2016

Testing commit 153f474 with merge db5280a...

bors-servo added 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

bors-servo commented Jan 22, 2016

💔 Test failed - travis

@jdm
Copy link
Member

jdm commented Jan 22, 2016

@bors-servo: retry

@bors-servo
Copy link
Contributor

bors-servo commented Jan 22, 2016

Testing commit 153f474 with merge 619a420...

bors-servo added 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

bors-servo commented Jan 22, 2016

💔 Test failed - travis

@jdm
Copy link
Member

jdm commented Jan 22, 2016

@bors-servo: retry

@bors-servo
Copy link
Contributor

bors-servo commented Jan 22, 2016

Testing commit 153f474 with merge 28dce6a...

bors-servo added 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

bors-servo commented Jan 22, 2016

💔 Test failed - travis

@jdm
Copy link
Member

jdm commented Jan 22, 2016

@bors-servo: retry

@bors-servo
Copy link
Contributor

bors-servo commented Jan 22, 2016

Testing commit 153f474 with merge ea0eb7e...

bors-servo added 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

bors-servo commented Jan 22, 2016

💔 Test failed - travis

@jdm
Copy link
Member

jdm commented Jan 23, 2016

@bors-servo: retry

@bors-servo
Copy link
Contributor

bors-servo commented Jan 23, 2016

Testing commit 153f474 with merge b2bd35f...

bors-servo added 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

bors-servo commented Jan 23, 2016

💔 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

bors-servo commented Jan 25, 2016

Testing commit 153f474 with merge c5bec7a...

bors-servo added 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

bors-servo commented Jan 25, 2016

💔 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 #29.
@pcwalton pcwalton force-pushed the pcwalton:linger branch from 153f474 to 0146ae7 Jan 25, 2016
@pcwalton
Copy link
Collaborator Author

pcwalton commented Jan 25, 2016

Forgot to commit changes. r? @jdm

@jdm
Copy link
Member

jdm commented Jan 25, 2016

@bors-servo
Copy link
Contributor

bors-servo commented Jan 25, 2016

📌 Commit 0146ae7 has been approved by jdm

@bors-servo
Copy link
Contributor

bors-servo commented Jan 25, 2016

Testing commit 0146ae7 with merge 3a95bec...

bors-servo added 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

bors-servo commented Jan 25, 2016

☀️ Test successful - travis

@bors-servo bors-servo merged commit 0146ae7 into servo:master Jan 25, 2016
1 check was pending
1 check was pending
homu Testing commit 0146ae7 with merge 3a95bec...
Details
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 added 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
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

3 participants
You can’t perform that action at this time.