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 upLimit Linux sockets to 32kB buffers. #57
Merged
Conversation
platform/linux/mod.rs
Outdated
| let (a, b) = (results[0], results[1]); | ||
|
|
||
| // Limit the buffers to 32kB. | ||
| let buf_sz: c_int = 32 * 1024; |
This comment has been minimized.
This comment has been minimized.
|
@bors-servo: r+ It's really annoying that this is necessary, but… |
|
|
bors-servo
added a commit
that referenced
this pull request
Mar 28, 2016
Limit Linux sockets to 32kB buffers. Based on [the code in `gonk/libui`](https://dxr.mozilla.org/mozilla-central/rev/63be002b4a803df1122823841ef7633b7561d873/widget/gonk/libui/InputTransport.cpp#130-134), this appears to fix servo/servo#9555.
|
|
antrik
added a commit
to antrik/ipc-channel
that referenced
this pull request
Apr 2, 2016
Just because we allocate a generous receive buffer for auxilllary data, doesn't mean that a message can't use the space for other things when it doesn't actually carry that amount of auxillary data. In fact, there is no reason to expect every message we receive to have auxillary data at all -- so let's just allocate a data buffer matching the total maximal receive size. This will enable some optimisations to be implemented; and it simplifies the code too. Note that the extra space is not used (yet) when the sender does explicit fragment size calculations; however, the sender presently tries to send the message in a single packet first, without any advace size checks at all -- so when the data size was close to the maximum packet size, this actually resulted in the message not fitting in the receive buffer! This is what caused servo/servo#10260 , which became (more) visible in Servo as a result of servo#57 -- though the underlying issue existed before...
antrik
added a commit
to antrik/ipc-channel
that referenced
this pull request
Apr 3, 2016
bors-servo
added a commit
that referenced
this pull request
Apr 6, 2016
Handle ENOBUFS by dynamically reducing packet size This is a better fix for servo/servo#9555 : handling the problem when it actually occurs, without affecting performance otherwise. It obsoletes (and removes) the workaround in #57
antrik
added a commit
to antrik/ipc-channel
that referenced
this pull request
Apr 6, 2016
Just because we allocate a generous receive buffer for auxilllary data, doesn't mean that a message can't use the space for other things when it doesn't actually carry that amount of auxillary data. In fact, there is no reason to expect every message we receive to have auxillary data at all -- so let's just allocate a data buffer matching the total maximal receive size. This will enable some optimisations to be implemented; and it simplifies the code too. Note that the extra space is not used (yet) when the sender does explicit fragment size calculations; however, the sender presently tries to send the message in a single packet first, without any advace size checks at all -- so when the data size was close to the maximum packet size, this actually resulted in the message not fitting in the receive buffer! This is what caused servo/servo#10260 , which became (more) visible in Servo as a result of servo#57 -- though the underlying issue existed before...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
eddyb commentedMar 28, 2016
Based on the code in
gonk/libui, this appears to fix servo/servo#9555.