executed tasks are leaked (testcase)

[njaard]

the c objects are never cleaned up even after the drop, which means that every proram that uses scoped-threadpool-rs leaks memory.

#[test]
fn no_leak() {
    let counters = ::std::sync::Arc::new(());

    let mut pool = Pool::new(4);
    pool.scoped(|scoped| {
        let c = ::std::sync::Arc::clone(&counters);
        scoped.execute(move || {
            let _c = c;
            ::std::thread::sleep(::std::time::Duration::from_millis(100));
        });
    });
    drop(pool);
    assert_eq!(::std::sync::Arc::strong_count(&counters), 1);
}

[mikeyhew]

but counters itself is a strong reference, so as long as it is alive, shouldn't the strong count be 1? If there was actually a leak, strong_count(&counters) would return 2: https://play.rust-lang.org/?gist=cc32e9dae811e8f0d397a31c004ff2c8

[njaard]

Well, yes, the test fails because the strong count is not 1.

[birkenfeld]

Works fine (test passes) for me (amd64 Linux; nightly and stable Rust; v0.1.8 of this crate). What configuration fails for you? Maybe it's a Rust or LLVM bug?

[mikeyhew]

@njaard

Well, yes, the test fails because the strong count is not 1.

Oh... I assumed you were using assert_eq to show that the strong count was 1. Silly me :)

[mikeyhew]

The test passes for me on the Playground: https://play.rust-lang.org/?gist=cedcfab5c332a5a58f61fb0d78389593&version=nightly

[Kimundi]

Seems the test still passes - @njaard in what situation did you observe a assertion failure?

[Boscop]

Any update on this? :)