Release the job after every cycle

[cekkr]

Has sense to implement a sched_yield() at every cycle in loopWhile() for making the loop a "little less blocking"?

Thank you

[jardicc]

Could you please elaborate a bit more about benefit of this? Maybe some real world example?

[cekkr]

The concept is this: I use deasync for programming simplification (and mainly laziness). The best use of node infact is through callbacks. But my worry is about the fact that a loop could use too many CPU resources. So offering the possibility to release the thread at every cycle you can check if the loop should continue just when the probability that loop conditions are changed is higher. But a similar implementation (this is must done directly in deasync) can be useful just if every time the thread is in execution continues to check the same condition occupying the processor for repeating an operation that probabilistically has the same result in the short term. With a similar feature you are more relaxed about the fact you are using a blocking loop in node but taking less CPU resources as possible.

[cekkr]

This feature is also useless if V8 use to execute every code and callback in the script with just one thread. In this case should be implemented a function that allows releasing the loop from the execution of the engine for passing to the next "operation stack"

[cekkr]

Forgive me, I'm trying to connect my brain. If a js script context runs on one only thread it's obvious that deasync for allowing the execution of other callbacks should allow to block the execution flow without be fully blocking.
But my logic is that: if you are waiting for a callback result you are respecting the I/O event-driven logic of node and you are using deasync just for implement in the most simplest way a form of "await". So, excluding a paralled heavy calculation inside the same context, my question if it's implemented a sort of sched_yield for making the thread more less CPU time occupier than possible.

Whenever I use deasync I can only think of the criticisms I have received for using a blocking function in an I / O driven system. So with an implementation like this I could part my heart in peace. Can I explain myself?

[cekkr]

Finally @jardicc I do not hide that I would learn better how V8 and modules like deasync work for various reasons, including knowing how to obtain the maximum possible performance

[jardicc]

I have just very little knowledge about this topic. But maybe could you fork it and see how it goes for yourself? :-)
You can always wrap callback into promise but then all parent functions in callstack has to be changed into async/await too to keep things in correct order. You have to change getters/setters into classic functions and whole codebase can get messy.

But at the same time if you are running server and you wait for deasync function to finish then server is simply frozen and unable to reply during deasync execution leading to errors and problems. So having something in between would amazing. But I am not C++ guy so I don't know whether this is possible or not.