Use `worker_threads` about make-synchronous HOT 8 OPEN

I plan on supporting worker_threads here soon.

from make-synchronous.

@mmkal This executes in a subprocess which has some benefits:

• Complete isolation.
• Cannot hang the process (worker threads can potentially hang the main process).
• Separate memory limit, so you could execute something that takes a lot of memory.

Yes, it's slower to launch a subprocess, but that only matters if you use it for short-running tasks. For long-running intensive tasks, the difference is neglible.

from make-synchronous.

Yeah, I've been thinking about moving to worker_threads (and removing the current child process implementation). When I initially made this package, I was not aware that it could be done with worker_threads too.

from make-synchronous.

Can I recommend user's to use synckit instead in the README?

from make-synchronous.

It's about 300x slower.

Your benchmark is flawed. You should run a heavy operation in the worker to actually test it, not just a lightweight task. Also, the task you are running in the worker (fs.promises.readFile) is already run in a background thread by Node.js.

from make-synchronous.

I plan on supporting worker_threads here soon.

That's great, I would follow your changes then.

from make-synchronous.

@sindresorhus I came here wondering what the advantages are of this over synckit. synckit seems well thought, fairly feature-rich out and widely used - do you think it's worth maintaining this rival at this point? Is there something missing from synckit that make-synchronous does better, or will do better?

This is a genuine question - it's often hard to tell what the tradeoffs of various libraries are, and maintainers tend to know best.

from make-synchronous.

Yes, it's slower to launch a subprocess, but that only matters if you use it for short-running tasks. For long-running intensive tasks, the difference is neglible.

Or if your task needs to be run many times, there will be huge difference too.

from make-synchronous.