feat: MultiProgress insert_from_back

[omjadas]

Add insert_from_back method to MultiProgress

[calmofthestorm]

It may not matter that much, but wouldn't that be subject to a race condition if another thread added a new progress bar between the call to len and the call to insert? Granted in practice this would result in the bars being added in unspecified order which is probably fine.

An alternative would be insert_from_back or to change insert to take negative numbers Python-style to indicate offset from the end.

I run into this when I have an overall status bar at the bottom, and then add subactions above, when there are enough subactions (or a more are added as we go) that the overall status bar would scroll offscreen.

[omjadas]

It may not matter that much, but wouldn't that be subject to a race condition if another thread added a new progress bar between the call to len and the call to insert? Granted in practice this would result in the bars being added in unspecified order which is probably fine.

I think just using insert without relying on the length of the MultiProgress could also result in a race condition. For example, if you were to insert multiple bars with the same index concurrently, you wouldn't have any guarantees as to which eventually resides at that index.

use indicatif::{MultiProgress, ProgressBar};
use std::{sync::Arc, thread};

fn main() {
    let mp = Arc::new(MultiProgress::new());
    let first_bar = ProgressBar::new(100);
    let second_bar = ProgressBar::new(100);

    let mp_1 = Arc::clone(&mp);
    let thread_1 = thread::spawn(move || {
        mp_1.insert(0, first_bar);
    });

    let mp_2 = Arc::clone(&mp);
    let thread_2 = thread::spawn(move || {
        mp_2.insert(0, second_bar);
    });

    thread_1.join().unwrap();
    thread_2.join().unwrap();

    // bars in mp have unknown order
}

A potential way this could be mitigated would be to change insert (and a potential insert_from_back) to require mutable references to self, requiring the user to deal with locking themselves.

[djc]

I'd prefer an insert_from_back()-like solution over this if that's the actual goal. I think externalizing the locking could be a different PR (or, at least, a different commit).

[omjadas]

I'd prefer an insert_from_back()-like solution over this if that's the actual goal. I think externalizing the locking could be a different PR (or, at least, a different commit).

@djc I have changed this PR to add an insert_from_back method. I agree that if the locks were to be externalized it should be a separate PR.

[djc]

Thanks!