Threads - sync vs async

[tamlyn]

I'm trying to understand the benefit of using the async methods in this lib.

In node.bcrypt.js, the async methods use threads under the hood to keep the expensive computations out of the main Node process.

By contrast this lib uses nextTick/setImmediate which just delays the expensive computation until the current call stack has completed. Doesn't this mean that several users logging in in quick succession could lock up the application?

If so is there a recommended way to mitigate this issue (e.g. using child_process or similar)?

[axelpale]

For clarity, could you point to the code area where nextTick is called? Maybe big async operations have been divided to multiple small parts, nextTick called after each, eventually making the operation to feel non-blocking.

[dcodeIO]

Async processing is located around here: https://github.com/dcodeIO/bcrypt.js/blob/master/src/bcrypt/impl.js#L429

Basically, what this does is splitting the operation into several chunks so that the main thread isn't blocked for the entire duration.

If you want to make it run on another thread, you could use sync methods within the context of a WebWorker or child_process.

[axelpale]

Seems legit. Chopping the operation into smaller pieces is the best what we can do with a single JS event loop. Also, this is what a IO scheduler basically does on a single CPU, slicing and pausing execution to share time. Of course, an OS/hardware level scheduler does it in more efficient manner, but if the optimal efficiency is one's number one priority, then one should consider using bcrypt over bcryptjs in the first place.

I guess this issue can be closed. However, the valuable knowledge created here could be also in the README.

[axelpale]

Created a PR (above) to mention this in the readme.

[tamlyn]

Thanks for the clarification. Hadn't realised that the computation itself is split into chunks. Makes sense.