Skip to content
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

Reason behind setImmediate(done)? #44

Milestone

Comments

@petasittek
Copy link

What is the reason of calling the callback function done() right at the beginning instead of the expected place - after the processing is done? Is there any speedup factor or? I find it quite confusing.

See: https://github.com/segmentio/metalsmith-permalinks/blob/16b3be73a18b33a0fab826cb46489d6f3cb9476e/lib/index.js#L35

@vitaliy-bobrov
Copy link

@petasittek ,
As I've read https://nodejs.org/api/timers.html#timers_setimmediate_callback_args, this takes done callback to the end of the event loop. I'm not sure, but may be it should be placed after all plugin manipulations.

@XhmikosR
Copy link
Contributor

Someone should look into using done() directly instead of setImmediate()

@webketje
Copy link
Member

webketje commented Aug 4, 2022

Logrocket has a good article about this: https://blog.logrocket.com/node-js-multithreading-worker-threads-why-they-matter/ (title: The naive solution: Synchronous code-splitting). The article admits "it’s hard to know where to put the setImmediate() to find a good balance.. In the context of this plugin, changing setImmediate(done) to just done() at the end would be clearer and very likely make no difference

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment