forked from checksum0/go-electrum
-
Notifications
You must be signed in to change notification settings - Fork 10
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
Expose the SubscribeHeadersSingle
function
#5
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lukasz-zimnoch
force-pushed
the
expose-subscribe-headers-single
branch
from
February 6, 2024 16:47
52c9940
to
7a03cc1
Compare
lukasz-zimnoch
force-pushed
the
expose-subscribe-headers-single
branch
from
February 6, 2024 16:49
7a03cc1
to
7a24220
Compare
tomaszslabon
reviewed
Feb 6, 2024
The `SubscribeHeadersSingle` function subscribes to receive the header of the current blockchain tip. Unlike `SubscribeHeaders`, this function only returns the tip and does not listen for new block headers. Worth noting that this action still creates a new subscription in the Electrum server. The protocol does neither support a single-shot request for the current blockchain tip nor subscription cancellation. Although this limitation causes a slight resource overhead on the client, it does not cause a memory leak like the `SubscribeHeaders` method which spawns a goroutine that may hang on the channel if the caller is no longer pulling from it.
lukasz-zimnoch
force-pushed
the
expose-subscribe-headers-single
branch
from
February 6, 2024 17:08
7a24220
to
ad5e3ac
Compare
tomaszslabon
approved these changes
Feb 6, 2024
lukasz-zimnoch
added a commit
to keep-network/keep-core
that referenced
this pull request
Feb 7, 2024
This is done in order to pull changes introduced in keep-network/go-electrum#5
lukasz-zimnoch
added a commit
to keep-network/keep-core
that referenced
this pull request
Feb 7, 2024
So far, `GetLatestBlockHeight` function used `SubscribeHeaders` under the hood. That caused a memory leak because `GetLatestBlockHeight` was not interested in reading from the returned `headersChan` channel. Each call to `GetLatestBlockHeight` produced a new dangling goroutine blocked on a buffered channel holding one item Here we replace `SubscribeHeaders` with `SubscribeHeadersSingle` which does not create a goroutine supposed to handle future headers notifications. The `SubscribeHeadersSingle` just return the current chain tip and ignores further notifications coming from the Electrum server. See keep-network/go-electrum#5 for further reference.
This was referenced Feb 7, 2024
tomaszslabon
added a commit
to keep-network/keep-core
that referenced
this pull request
Feb 8, 2024
Closes: #3739 Depends on: keep-network/go-electrum#5 Depends on: #3774 So far, the `GetLatestBlockHeight` function of the Electrum client was using `go-electrum`'s `SubscribeHeaders` under the hood. That caused a memory leak because `GetLatestBlockHeight` was not interested in reading from the returned `headersChan` channel. Each call to `GetLatestBlockHeight` produced a new dangling goroutine blocked on a buffered channel with one item inside. Here we replace `SubscribeHeaders` with `SubscribeHeadersSingle` which does not create a goroutine supposed to handle future headers notifications. The `SubscribeHeadersSingle` just returns the current chain tip and ignores further notifications coming from the Electrum server. See keep-network/go-electrum#5 for further reference.
lukasz-zimnoch
added a commit
to keep-network/keep-core
that referenced
this pull request
Feb 12, 2024
This is done in order to pull changes introduced in keep-network/go-electrum#5 (cherry picked from commit b3b800c)
lukasz-zimnoch
added a commit
to keep-network/keep-core
that referenced
this pull request
Feb 12, 2024
So far, `GetLatestBlockHeight` function used `SubscribeHeaders` under the hood. That caused a memory leak because `GetLatestBlockHeight` was not interested in reading from the returned `headersChan` channel. Each call to `GetLatestBlockHeight` produced a new dangling goroutine blocked on a buffered channel holding one item Here we replace `SubscribeHeaders` with `SubscribeHeadersSingle` which does not create a goroutine supposed to handle future headers notifications. The `SubscribeHeadersSingle` just return the current chain tip and ignores further notifications coming from the Electrum server. See keep-network/go-electrum#5 for further reference. (cherry picked from commit fb91c33)
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.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refs: keep-network/keep-core#3739
The
SubscribeHeadersSingle
function subscribes to receive the header of the current blockchain tip. UnlikeSubscribeHeaders
, this function only returns the tip and does not listen for new block headers.Worth noting that this action still creates a new subscription in the Electrum server. The protocol does neither support a single-shot request for the current blockchain tip nor subscription cancellation. Although this limitation causes a slight resource overhead on the client, it does not cause a memory leak like the
SubscribeHeaders
method which spawns a goroutine that may hang on the channel if the caller is no longer pulling from it.