Single-threaded MultiProgress

[Ralith]

MultiProgress seems to conflate support for displaying and update multiple progress bars concurrently and support for updating progress bars from multiple threads. It would be nice to isolate these so that a single thread performing multiple tasks can effectively use MultiProgress. Inter-thread communication could perhaps even be left up to the user.

[repi]

Ran into this issue directly today also when I tried out this crate.

I had some single-threadedcode that has multiple progress bars that I want to be able to update but they didn't show up at all when using MultiProgress, and creating multiple individual ProgressBar created conflicted output.

[mitsuhiko]

Yeah. I wanted to clean this up already. For now I'm accepting pull requests to make this better because I did not come up with a nice design for it.

[Ralith]

In the end I went ahead and published my own progress bar crate, yapb, which has a much simpler implementation and does not make assumptions about use patterns or even IO.

[fiws]

Had this problem with futures today. Lots of stuff to progress, but only one thread.

[marienz]

#231 and #234 may address this: the former makes ProgressBars in a MultiProgress update their shared draw target synchronously, the latter reworks batching / ratelimiting of terminal updates so it's fully shared by MultiProgress and single bars.

After those two changes, MultiProgress no longer requires using a separate thread to run update(), and is entirely single-threaded when updates are not ratelimited (using stderr_nohz() or similar). When using ratelimited drawing (with either a single bar or MultiProgress), the library manages a background thread to buffer updates and write to the terminal.

(I still don't really like this design: seems like the draw targets should only receive notifications that state changed, not a full draw state, and the draw targets should then be able to request the bars to render themselves when they want to redraw. That'd mean less wasted work, and the possibility of doing something like steady_tick and redraws on terminal size changes in the draw target. That's more of a redesign than I'd like to tackle, though.)

[NathanHowell]

while not ideal, it does work if you can spin up a separate thread for the MultiProgress instance:

let multi_progress = MultiProgress::new();
let progress_one = mp.add(ProgressBar::new_spinner());
let progress_two = mp.add(ProgressBar::new_spinner());
let progress_three = mp.add(ProgressBar::new_spinner());
let multi_progress = thread::spawn(move || multi_progress.join());

// do work
for i in 0..10 {
    progress_one.inc(1);
    progress_two.inc(1);
    progress_three.inc(1);
}

progress_one.finish();
progress_two.finish();
progress_three.finish();

multi_progress.join().unwrap();

[djc]

#231 was merged by way of #284. I'm not completely sure the current state addresses the original concerns so I'll leave this open for now, but I think the state in the soon to be released 0.17 (#318) is substantially improved.

[chris-laplante]

I'm going to close this. MultiProgress no longer necessitates another thread for drawing. It's been like that for a few years now.