-
Notifications
You must be signed in to change notification settings - Fork 415
Async persister #3905
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
base: main
Are you sure you want to change the base?
Async persister #3905
Conversation
👋 Hi! I see this is a draft PR. |
1b95d30
to
21dc34c
Compare
/// # struct Store {} | ||
/// # impl lightning::util::persist::KVStore for Store { | ||
/// # struct StoreSync {} | ||
/// # impl lightning::util::persist::KVStoreSync for StoreSync { |
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.
This is what we'd get with a partial conversion. Chain monitor still requires a sync implementation of the kv store for now.
Do we really not want to provide a wrapper here that uses block_on to syncify the async kvstore?
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.
I really don't buy that we do, given the rate of issues that we've seen with hang-risk from block_on. In practice I imagine most implementations should be able to do it themselves pretty easily.
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.
So go with the dual trait approach for now, requiring async users to implement both?
651ea9f
to
1006cee
Compare
3fb7d6b
to
1847e8d
Compare
1847e8d
to
1f59bbe
Compare
Also provide a wrapper to allow a sync kvstore to be used.
1f59bbe
to
723a5a6
Compare
Stripped down version of #3778