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

Fix panic caused by race condition when writing while dropping reader #16

Merged
merged 3 commits into from
Jan 30, 2021

Conversation

sagebind
Copy link
Owner

Writer has a race condition that might cause a panic if poll_write is called more than once while the Reader is in the processed of being dropped on another thread.

The race condition is caused by the drop order of Reader: Since fields are dropped in the order they are defined in, the buffer pool channel is dropped before the buffer stream channel. If poll_write is called more than once between these two drop calls, then the underlying channel will panic because we've polled it after already returning None.

The fix is to ensure the buffer stream channel is closed first before the buffer pool channel, since that is the channel we use to detect when the reader is closed. One way of doing this would be to just reverse the order these two fields are defined in, but it is better to be clear that the drop order matters by using an explicit drop handler.

With this fix, we know that the second channel will be polled at most once when closed, because subsequent calls to poll_write will check the first channel before polling the second.

See also sagebind/isahc#295.

`Writer` has a race condition that might cause a panic if `poll_write` is called more than once while the `Reader` is in the processed of being dropped on another thread.

The race condition is caused by the drop order of `Reader`: Since fields are dropped in the order they are defined in, the buffer pool channel is dropped _before_ the buffer stream channel. If `poll_write` is called more than once between these two drop calls, then the underlying channel will panic because we've polled it after already returning `None`.

The fix is to ensure the buffer stream channel is closed _first_ before the buffer pool channel, since that is the channel we use to detect when the reader is closed. One way of doing this would be to just reverse the order these two fields are defined in, but it is better to be clear that the drop order matters by using an explicit drop handler.

See also sagebind/isahc#295.
@sagebind sagebind added the bug Something isn't working label Jan 30, 2021
@sagebind sagebind merged commit 8ca411f into master Jan 30, 2021
@sagebind sagebind deleted the write-while-dropping-race-condition branch January 30, 2021 17:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant