-
Notifications
You must be signed in to change notification settings - Fork 43
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
perf: use async fs & crypto methods #672
Conversation
4568680
to
0ec10a1
Compare
There's definitely no excuse for blocking the thread on Nodejs, since it was created for async I/O, and so all the libs support that. I think we introduced some sync version usages because we needed it in the constructor, but this should be avoided as well. Looks great! |
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.
Looks nice. Excited to get this merged.
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.
Needs a rebase. Otherwise good to go.
This replaces all synchronous calls to the NodeJS `fs` and `crypto.randomBytes` methods with asynchronous calls. This improves performance by preventing blocking of the event loop.
This creates a unit test suite for the node key module. Currently the only test verifies that it will generate a valid node key.
0ec10a1
to
03fdd41
Compare
This fixes a bug introduced in #672 whereby the lnd clients are not properly initializing. That PR removed synchronous calls to methods that had asynchronous alternatives, which necessitated moving code from the synchronous `LndClient` constructor to an asynchronous init method. Included in the code that was moved was logic to determine whether to change the client's status from the default value of `Disabled`. This impacted the xud initialization procedure which would only attempt to initialize (or previously verify a connection for) an lnd client that was not disabled. This PR creates a new `NotInitialized` status as the default to reflect the status of a newly created client. It gets changed when the `init` method is called.
This fixes a bug introduced in #672 whereby the lnd clients are not properly initializing. That PR removed synchronous calls to methods that had asynchronous alternatives, which necessitated moving code from the synchronous `LndClient` constructor to an asynchronous init method. Included in the code that was moved was logic to determine whether to change the client's status from the default value of `Disabled`. This impacted the xud initialization procedure which would only attempt to initialize (or previously verify a connection for) an lnd client that was not disabled. This PR creates a new `NotInitialized` status as the default to reflect the status of a newly created client. It gets changed when the `init` method is called.
This replaces all synchronous calls to the NodeJS
fs
andcrypto.randomBytes
methods with asynchronous calls. This improves performance by preventing blocking of the event loop. I was inspired after reading Don't Block the Event Loop. Most of the benefit is during startup/initialization, but there should also be a small benefit when proposing swaps which should happen quite frequently.I also added a test suite for NodeKey.ts, I was primarily motivated by having a quick way to test that the async
crypto.randomBytes
call was working but it would also be good expand in the future.