-
Notifications
You must be signed in to change notification settings - Fork 154
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
Conversation
a6752e0
to
9b86fdb
Compare
@@ -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(); |
There was a problem hiding this comment.
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()
There was a problem hiding this comment.
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
There was a problem hiding this 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), |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup
There was a problem hiding this 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
this is another case where an error would be a logic error, hence the comment, and panicking is thus preferred |
AsyncSender::is_writable
andwait_writable
indicate if/when the channel might be writable, but they do not guarantee the channel is actually writable. This means ifwait_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.