fix: not panic in destructor

[zhangli-pear]

release_resource should not panic. Because with_thread_data may return a ThreadData on the stack, and it's empty.

[zhangli-pear]

following code can reproduce the problem if deadlock_detection feature was enabled.

use std::thread;
use parking_lot::RwLock;

struct Bar(RwLock<()>);

impl Drop for Bar {
    fn drop(&mut self) {
        let _n = self.0.write();
    }
}

thread_local! {
    static B: Bar = Bar(RwLock::new(()));
}

fn main() {
    thread::spawn(|| {
        let a = RwLock::new(());
        let _a = a.read();

        B.with(|_| ());
    }).join().unwrap();
}

[Amanieu]

I can't reproduce the panic with your example code. Are you sure you are using the latest version of parking_lot?

[zhangli-pear]

I can't reproduce the panic with your example code. Are you sure you are using the latest version of parking_lot?

Did you enable deadlock_detection feature?
I'm using 0.9.0 in my project, but latest version is the same.

[Amanieu]

Yes I enabled deadlock_detection. However no matter how I run your code, I can't get it to panic.

[Amanieu]

Can you try deleting your Cargo.lock to see if this helps?

[quininer]

This seems to happen only on macOS, it is same issue as #114.

[Amanieu]

Right I think I know what the problem is. Basically, the internal ThreadData in parking_lot is getting dropped before the RwLock, which causes all sorts of issues. I'll need to re-read the code to figure out all the implications.

[quininer]

use std::thread;
use parking_lot::RwLock;

struct Bar(RwLock<()>);

impl Drop for Bar {
    fn drop(&mut self) {
        let _n = self.0.write();
    }
}

thread_local! {
    static B: Bar = Bar(RwLock::new(()));
}

fn main() {
    thread::spawn(|| {
        B.with(|_| ());

        let a = RwLock::new(());
        let _a = a.read();
    }).join().unwrap();
}

reversing init order of tld can make it reproduce on linux.

[Amanieu]

I think a more general solution is needed here: the deadlock detector needs to be able to handle threads that have exited while still holding leaked locks.

[zhangli-pear]

I think a more general solution is needed here: the deadlock detector needs to be able to handle threads that have exited while still holding leaked locks.

maybe not using thread_local?

[Amanieu]

Actually after reviewing the code, I'm just going to go with your solution.

[Amanieu]

bors r+

[bors]

Build succeeded

• continuous-integration/appveyor/branch
• continuous-integration/travis-ci/push