Is your feature request related to a problem? Please describe.
This is very common feature, it's implemented in very old back-end engines like FoxPro
Describe the solution you'd like
process.halt() / process.resume().. or alike
process.halt - pauses current routine only, other events/callbacks run as usual
process.resume - resumes paused routine
these functions may take a parameter which will act as an identifier of halted routine
Describe alternatives you've considered
there is only one alternative to promisify everything in array with async/await, timeouts or other similar constructs.
why it's important: it will "flatten" all code and make it way more simplier for cli/automation scripts.
also, docs design/organization is not very readable.. im a newbie to node.js
@determin1st Can you explain what exactly this feature would do?
well, it would halt current function/file execution and run events/everything else..
it also needs counter-part to resume/return.
// stage 1
// .. set events ..
someEventObject.on('something', function(params) {
// ...
process.continue();// this will unblock/release/continue
});
process.hlt();// .. this will wait/skip/halt current/proceed event loop ..
// stage 2
// ... set events ...
process.hlt();
// ...
// stage 3
// ... set events ...
process.hlt();
// ...
sorry, i don't know if it possible for node.js.
Currently the constructs needed to facilitate this behavior in NodeJS involve a yield/return path up to the top-most asynchronous caller which is the event loop executor itself. It may sometimes require undue technical debt to implement such a return path if such behavior is used often. The alternative solution to "promisify everything" implies wrapping all functions within the async callback in Promises which compose a continuation chain rather than a stack (CPS coroutines), thus minimizing the size of the aforementioned return path.
Userspace solution:
const Halter = () => {
const waiting = [];
return {
hlt: () =>
new Promise(resolve =>
waiting.push(resolve)),
continue: x =>
waiting
.splice(0, Infinity)
.map(f =>
f(x))
.length
};
};
Usage:
const proc = Halter();
(async () => {
someEventObject.on('something', function (params) {
proc.continue();
});
await proc.hlt(); // Will block current function until the event arrives
// This runs after the event has arrived
console.log('got event');
})();
Alternatively, with args:
const proc = Halter();
(async () => {
someEventObject.on('something', function (event) {
proc.continue(event);
});
const event = await proc.hlt(); // Will block current function until the event arrives
// This runs after the event has arrived
console.log('got event: ', event);
})();
@trgwii thanks for nice try, but it doesn't work for nested functions which use this Halter, every function must be declared as async and every call must be prefixed with await construct. this only adds more complexity.
If you want to automatically halt all parent functions too, sync or async, you could do a while (true); but that would prevent the event loop from turning as well. These are the options
halting is not blocking, it shouldn't eat event loop. i've already made something but you didn't like it :]
all this async revolution drives me nuts.
I think this has been answered so I'm going to close it out. If there's still more to discuss, it should probably be moved to nodejs/help.

@determin1st name calling is not appropriate. Please see how to conduct yourself in the repo if unsure.
I have deleted the offending comment. I'm looking forward to more constructive and meaningful interactions with you in the future.
Most helpful comment
Currently the constructs needed to facilitate this behavior in NodeJS involve a yield/return path up to the top-most asynchronous caller which is the event loop executor itself. It may sometimes require undue technical debt to implement such a return path if such behavior is used often. The alternative solution to "promisify everything" implies wrapping all functions within the async callback in Promises which compose a continuation chain rather than a stack (CPS coroutines), thus minimizing the size of the aforementioned return path.