Skip to content

Make ChangeDestinationSourceSyncWrapper pub #3787

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.

Sign up for GitHub

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

Closed
wants to merge 1 commit into from
Closed

Make ChangeDestinationSourceSyncWrapper pub #3787

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 0 additions & 5 deletions lightning/src/sign/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -996,12 +996,7 @@ pub trait ChangeDestinationSourceSync {
}

/// A wrapper around [`ChangeDestinationSource`] to allow for async calls.
#[cfg(any(test, feature = "_test_utils"))]
pub struct ChangeDestinationSourceSyncWrapper<T: Deref>(T)
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you still need this public when using OutputSweeperSync which does the wrapping for you?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Currently yes: in LDK node we use (and like to continue using) the async BackgroundProcessor, which however only works with OutputSweeper, not OutputSweeperSync. So we need to wrap ourselves, see this commit: lightningdevkit/ldk-node@bd46d1f

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm if we do this, isn't this going to risk blocking tokio?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ugh, you're right. Not in LDK Node (as we know the implementation is sync), but in general yes, this would open us up to the footgun we discussed previously. Kinda telling that I already almost forgot... Maybe the ChangeDestinationSourceSync could use some additional docs reminding us that we can only ever implement it via OutputSweeperSync?

I guess I'll need to do the ugly thing then and use spawn_blocking in the async ChangeDestinationSource.

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe the ChangeDestinationSourceSync could use some additional docs reminding us that we can only ever implement it via OutputSweeperSync

Yes can add that.

I guess I'll need to do the ugly thing then and use spawn_blocking in the async ChangeDestinationSource.

That is indeed the consequence of calling the sweeper from an async context. Isn't it possible to create a native async ChangeDestinationSource in ldk-node?

Copy link
Contributor Author

@tnull tnull May 21, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Isn't it possible to create a native async ChangeDestinationSource in ldk-node?

It is, should have gone that way from the beginning, even though it entailed some annoying refactoring: lightningdevkit/ldk-node@c7b74640

Copy link
Contributor

Choose a reason for hiding this comment

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

Looks good. This is what we always wanted, isn't it?

where
T::Target: ChangeDestinationSourceSync;
#[cfg(not(any(test, feature = "_test_utils")))]
pub(crate) struct ChangeDestinationSourceSyncWrapper<T: Deref>(T)
where
T::Target: ChangeDestinationSourceSync;

Expand Down
Loading