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

zhttpsocket: proper handling of is_writable #47882

Merged
merged 1 commit into from
Jan 24, 2024
Merged

Conversation

jkarneges
Copy link
Member

AsyncSender::is_writable and wait_writable indicate if/when the channel might be writable, but they do not guarantee the channel is actually writable. This means if wait_writable().await is followed by a non-blocking send, the possibility of the send failing must still be handled. This change ensures failed sends are reattempted when writability is indicated again.

This change also corrects check_send_any to wait for at least one handle to be writable instead of waiting for all to be writable, and it clarifies the various sending error scenarios.

@jkarneges jkarneges force-pushed the jkarneges/handle-send-fix branch from a6752e0 to 9b86fdb Compare January 22, 2024 19:36
@@ -292,11 +297,15 @@ impl SessionData {
}
}

fn add(&self, key: SessionKey, handle_index: usize) -> Result<Session, ()> {
fn add(&self, key: SessionKey, handle_index: usize) -> Result<Session, SessionAddError> {
let inner = &mut *self.inner.lock().unwrap();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mutex handling can be improved improved by handling the potential error that can occur when locking the mutex, instead of using unwrap()

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lock() fails if the mutex is poisoned, which means we have a logic error and so it's reasonable to abort the program on the spot

Copy link
Contributor

@sima-fastly sima-fastly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there are a few places in this file where we see unwrap() instead of err handling such as

            // can't fail
            let (frame, _) = tnetstring::parse_frame(mi.data).unwrap();

do you think adding some log lines in these cases would be helpful instead of panic ?

match ret {
Ok(()) => {}
Err(StreamHandlesSendError::BadFormat) => warn!("stream send_any: bad format"),
Err(StreamHandlesSendError::NoneReady) => *next_msg = Some(msg),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this *next_msg = Some(msg) for retry purposes?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup

Copy link
Contributor

@sima-fastly sima-fastly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall looks great 🎖️
posted some comments and Qs

@jkarneges
Copy link
Member Author

there are a few places in this file where we see unwrap() instead of err handling such as

            // can't fail
            let (frame, _) = tnetstring::parse_frame(mi.data).unwrap();

do you think adding some log lines in these cases would be helpful instead of panic ?

this is another case where an error would be a logic error, hence the comment, and panicking is thus preferred

@jkarneges jkarneges merged commit 42ac17c into main Jan 24, 2024
1 check passed
@jkarneges jkarneges deleted the jkarneges/handle-send-fix branch January 24, 2024 00:18
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.

2 participants