-
Notifications
You must be signed in to change notification settings - Fork 407
BackgroundProcessor is not wasm-web compatible #1864
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
Milestone
Comments
I think we can make the |
TheBlueMatt
added a commit
to TheBlueMatt/rust-lightning
that referenced
this issue
Jan 17, 2023
`background-processor` does a number of jobs on various timers. Instead of doing those by interrogating `std::time::Instant`, this change swaps to using the existing user-provided sleep future. Fixes lightningdevkit#1864.
vss96
pushed a commit
to vss96/rust-lightning
that referenced
this issue
Mar 6, 2023
`background-processor` does a number of jobs on various timers. Instead of doing those by interrogating `std::time::Instant`, this change swaps to using the existing user-provided sleep future. Fixes lightningdevkit#1864.
optout21
pushed a commit
to optout21/rust-lightning
that referenced
this issue
Jul 24, 2023
`background-processor` does a number of jobs on various timers. Instead of doing those by interrogating `std::time::Instant`, this change swaps to using the existing user-provided sleep future. Fixes lightningdevkit#1864.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Because
BackgroundProcessor::start
usesstd::thread
andstd::time::Instant
this function is unable to be called in a wasm runtime. It would be great if these were able to be abstracted out or a separate version that didn't require these was available so everything could be run in the browser.For now our solution is just copy-pasting the
define_run_body
macro into our own code and seeing if we can get that to work. However, this is not the best alternative as we'd like to just use what rust-lightning has so we don't need to check if this macro has changed every time we update the dependency.The text was updated successfully, but these errors were encountered: