-
Notifications
You must be signed in to change notification settings - Fork 386
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
Don't return channel_state
from decode_update_add_htlc_onion
#1638
Don't return channel_state
from decode_update_add_htlc_onion
#1638
Conversation
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.
ACK 2292538
Looks good!
Seems the GH actions error is just a transient crates one.
lightning/src/ln/channelmanager.rs
Outdated
@@ -2246,13 +2241,13 @@ impl<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelMana | |||
} | |||
}; | |||
|
|||
channel_state = Some(self.channel_state.lock().unwrap()); | |||
let mut channel_state = self.channel_state.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.
While you're here, can you move this down inside if let Some((err, code, chan_update)) = loop {
? That way we're not holding the lock at all if we call return_err
later.
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 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.
Nvm, I'll take the channel_state lock temporarily for the short_to_chan_info and then drop it.
36ce228
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.
Please don't lock+unlock twice immediately back-to-back? That's unnecessary.
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.
Wow.. Honestly disappointed in myself that I pushed that yesterday night.
Fixed with: 4a07ac0
36ce228
to
4a07ac0
Compare
LGTM, feel free to squash. |
Currently `decode_update_add_htlc_onion` returns the `channel_state` lock to ensure that `internal_update_add_htlc` holds a single `channel_state` lock in when the entire function execution. This is unnecessary, and since we are moving the channel storage to the `per_peer_state`, this no longer achieves the goal it was intended for. We therefore avoid returning the `channel_state` from `decode_update_add_htlc_onion`, and just retake the lock in `internal_update_add_htlc` instead.
4a07ac0
to
65e6fb7
Compare
Squashed without changes. Thanks for the reviews @dunxen & @TheBlueMatt! |
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.
ACK 65e6fb7
Unrelated: I remember now @TheBlueMatt mentioned that GH actions weirdness with that specific Rust version :/
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.
LGTM
Prerequisite for #1507, and addresses comment #1507 (comment).
Currently
decode_update_add_htlc_onion
returns thechannel_state
lock to ensure that
internal_update_add_htlc
holds a singlechannel_state
lock in when the entire function execution. This isunnecessary, and since we are moving the channel storage to the
per_peer_state
, this no longer achieves the goal it was intended for.We therefore avoid returning the
channel_state
fromdecode_update_add_htlc_onion
, and just retake the lock ininternal_update_add_htlc
instead.