You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But wrapping execution of the operation function and recursive call in a setImmediate will allow the EventLoop itself handle the scheduling. It seems rather bad practice to try to control scheduling of the EventLoop within the application layer.
In the end, the exercise was to write non-blocking code. Even if the callback only fires once, before the EventLoop schedules the interrupt, then the test should pass because the goal of the exercise was accomplished (learn how to release control to the EventLoop).
The solution does sets an odd, arbitrary threshold for releasing control to the event loop:
https://github.com/timoxley/functional-javascript-workshop/blob/master/exercises/blocking_event_loop/solution/solution.js#L6-L9
This arbitrary assumption is coded into the test runner for this exercise, tightly coupling the two:
https://github.com/timoxley/functional-javascript-workshop/blob/master/exercises/blocking_event_loop/wrapper.js#L34-L37
But wrapping execution of the
operation
function and recursive call in asetImmediate
will allow the EventLoop itself handle the scheduling. It seems rather bad practice to try to control scheduling of the EventLoop within the application layer.https://repl.it/@RavenHursT/Functional-JS-Workshop-Exercise-13-Solution
In the end, the exercise was to write non-blocking code. Even if the callback only fires once, before the EventLoop schedules the interrupt, then the test should pass because the goal of the exercise was accomplished (learn how to release control to the EventLoop).
For further reference: https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/
The text was updated successfully, but these errors were encountered: