Skip to content

Add a MutexGuard wrapper for the bindings-only LockableScore #1729

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

Merged

Conversation

TheBlueMatt
Copy link
Collaborator

In the bindings, we don't directly export any std types. Instead, we provide trivial wrappers around them which expose only a bindings-compatible API (and which is code in-crate, where the bindings generator can see it).

We never quite finished this for MultiThreadedLockableScore - due to some limitations in the bindings generator and the way the scores are used in lightning-invoice, the scoring API ended up being further concretized in patches for the bindings. Luckily the scoring interface has been rewritten somewhat, and it so happens that we can now generate bindings with the upstream code.

The final piece of the puzzle is done here, where we add a struct which wraps MutexGuard so that we can expose the lock for MultiThreadedLockableScore.

In the bindings, we don't directly export any `std` types. Instead,
we provide trivial wrappers around them which expose only a
bindings-compatible API (and which is code in-crate, where the
bindings generator can see it).

We never quite finished this for `MultiThreadedLockableScore` - due
to some limitations in the bindings generator and the way the
scores are used in `lightning-invoice`, the scoring API ended up
being further concretized in patches for the bindings. Luckily the
scoring interface has been rewritten somewhat, and it so happens
that we can now generate bindings with the upstream code.

The final piece of the puzzle is done here, where we add a struct
which wraps `MutexGuard` so that we can expose the lock for
`MultiThreadedLockableScore`.
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