Description
Extracted from #20059.
std.Progress
is currently implemented to do nothing for single-threaded builds:
Line 336 in 963ffe9
This means as a parent process it does not draw progress to the terminal, and as a child process it does not send progress updates to the parent over the provided pipe.
It could be implemented to share code with the multi-threaded version by doing the update thread's task, or the IPC thread's task in the function body of Node.end
for example. It would be slightly less accurate than the threaded version because updates would only occur when starting or stopping another node - which means there is a pattern that could lead to a shorter-running Node being blamed for what was actually a longer-running Node's operation. It would work decently enough though.
Is it worth it? I think the perf penalty would be higher for single-threaded processes. I'm not sure if it would be worth it.