Skip to content

Conversation

@TheBlueMatt
Copy link
Contributor

@TheBlueMatt TheBlueMatt commented Nov 5, 2025

Updates to support lightningdevkit/rust-lightning#4175 as described at lightningdevkit/rust-lightning#4175 (comment)

Commit messages need cleaning up and rustfmt, but otherwise its probably good.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Nov 5, 2025

👋 I see @joostjager was un-assigned.
If you'd like another reviewer assignment, please click here.

Copy link
Collaborator

@tnull tnull left a comment

Choose a reason for hiding this comment

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

I have to say I'm not the biggest fan of all this additional boilerplate, especially since that will get even bigger when we finally support and make use of async versions of the MigratableKVStore and PaginatedKVStore. I also don't quite buy that the added complexity is worth saving some boxing, especially given that tokio will auto-box all read/write tasks as they are simply too big for the stack (according to tokio at least).

Note this already needs a rebase, and also doesn't compile under cargo build --features uniffi currently.

Given that this will likely introduce a lot of conflicts with #692 and make the changes there even more complex, I might be good to hold off on this (and by extension the upstream API-breaking changes until after #692 lands).

@TheBlueMatt
Copy link
Contributor Author

TheBlueMatt commented Nov 6, 2025

especially since that will get even bigger when we finally support and make use of async versions of the MigratableKVStore and PaginatedKVStore.

I think we'll survive three or four more methods :)

I also don't quite buy that the added complexity is worth saving some boxing, especially given that tokio will auto-box all read/write tasks as they are simply too big for the stack

No, tokio will auto-box the top-of-task future, but everything below that gets compiled into a single object when you have concrete future types. This should nontrivially reduce boxing, which I imagine are a decent chunk of our allocations, or at least on ldk-sample write-related allocations were so I have to imagine still are. Of course we don't reduce allocations in ldk-node because you wanted to keep the kvstore type dyn, but for folks like c= it'll be a pretty nontrivial win.

Given that this will likely introduce a lot of conflicts with #692 and make the changes there even more complex, I might be good to hold off on this (and by extension the upstream API-breaking changes until after #692 lands).

Seems reasonable to hold off on landing this, but I don't see why that has to delay landing the PR upstream? Its somewhat annoying to rebase a PR that touches a bunch of code across rust-lightning crates, and I'm happy to rebase this PR right away once #692 lands so that ldk-node doesn't slip too far behind rust-lightning.

@TheBlueMatt TheBlueMatt marked this pull request as ready for review December 8, 2025 15:50
In the next commit we'll update `rust-lightning` with the
`Pin<Box<dyn ...>>` pattern dropped in favor of native async traits
(with `impl Future...`). In anticipation of those traits becoming
not-object-safe here we drop the dyn indirection that exists in our
gossip validation.
@TheBlueMatt TheBlueMatt force-pushed the 2025-11-impl-traits branch 2 times, most recently from ba5c9b7 to 1f9c6b7 Compare December 8, 2025 15:54
@TheBlueMatt
Copy link
Contributor Author

Rebased and updated the LDK commit to latest git from today.

In `rust-lightning` we dropped the `Pin<Box<dyn ...>>` in favor of
`impl Future`s on most traits to make the traits native-async-ish.
Here we update to implement that change here.

However, because we avoid generics in ldk-node through concrete dyn
indirections, and having implict associated types on
`rust-lightning` traits makes them not-object-safe, we have to do
a bit of indirection. Instead, we define a `DynStoreTrait` which
re-concretizes the `rust-lightning` storage traits, allowing us to
use them `dyn`.
@tnull tnull removed the request for review from joostjager December 8, 2025 16:51
Copy link
Collaborator

@tnull tnull left a comment

Choose a reason for hiding this comment

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

LGTM

We'll revisit a lot of the same places in #692 I'm afraid.

@tnull tnull merged commit 5d0fb14 into lightningdevkit:main Dec 8, 2025
18 checks passed
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.

3 participants