Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 3.2k
implement std.Progress for single-threaded mode #20101
Copy link
Copy link
Open
Labels
enhancementSolving this issue will likely involve adding new logic or components to the codebase.Solving this issue will likely involve adding new logic or components to the codebase.standard libraryThis issue involves writing Zig code for the standard library.This issue involves writing Zig code for the standard library.
Milestone
Description
Activity
Metadata
Metadata
Assignees
Labels
enhancementSolving this issue will likely involve adding new logic or components to the codebase.Solving this issue will likely involve adding new logic or components to the codebase.standard libraryThis issue involves writing Zig code for the standard library.This issue involves writing Zig code for the standard library.
Extracted from #20059.
std.Progressis currently implemented to do nothing for single-threaded builds:zig/lib/std/Progress.zig
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.endfor 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.