Drop Trait blocked for variables given to the worker thread about chan-signal HOT 6 CLOSED

What problem are you trying to solve by implementing a Drop constructor?

More generally, the very specific piece of code you've written here seems to be acting as I would expect. You're moving thing2 into run, which never terminates, and therefore thing2 is never dropped. I don't think this issue has anything to do with chan-signal specifically, but it's hard to know without knowing what problem you're trying to solve.

from chan-signal.

I want to read and write the gpios of the raspberry pi. For that I have to write into files like it is dokumented here, to export and unexport them.
I provided a GPIO struct in a separate library (a project for me to learn more about the raspi, as well as rust)
The struct implements the Drop trait where the gpio will be unexported.

For test purposes, I wanted to write a program which creates (export) a GPIO, read out its value in an endless loop (which I placed in the worker thread), which would be terminated on a SIGINT.
After termination I wanted the the GPIO struct to run regularly out of scope, so that it will be unexported in the destructor.

Your library seemed to fit my purposes and was easily included in my project. Your example seemed to be strait forward, but reading your answer, I might have miss interpreted the threading part (I haven't read about thread handling in rust yet). I assumed the worker thread to be terminated after the SIGINT was received, but in your answer you stated that it actually never terminates.

So in my particular case the thing structs are actually GPIO structs. The rest would be pretty much the same.
I hope with that my intend got clearer. If not feel free to ask.

Do you have any suggestion how to address this problem properly (if possible)?

from chan-signal.

Take a look at your function:

fn run(thing:  Thing, _sdone: chan::Sender<()>) {
    let thing3 = Thing{a_thing: 3};
    loop {
    }
}

The destructor for thing is run at the end of run, but the end of run is impossible to reach because of loop {}, which is an infinite loop. That's all there is to it.

You need to find a way to terminate run gracefully, probably with another channel.

from chan-signal.

I expected that the destructor of thing3 would never be hit. Thing2 was the one I expected to be destructed after receiving the signal.

But I can achieve my goal using your signals, entirely without threading, when I check the signals inside the loop like this (inspired by one of your examples):

fn main() {
    let signal = chan_signal::notify(&[Signal::INT, Signal::TERM]);
    let mut thing = Thing{a_thing: 1};
    loop {
        chan_select! {
            default => {},
            signal.recv() -> signal => {
                println!("received signal: {:?}", signal);
                break;
            },
        }
       //do something with the thing
    }
}

Thank you for your time and the work on signal handling with rust!

from chan-signal.

@Skasselbard But when you call run, you're moving thing2 into run, which means the thing2 won't get dropped until the end of run. The relationship with thing3 is that thing2 will get dropped after thing3, but the scope of both extends to the end of run. If run never ends, then the destructors for thing2 and thing3 won't ever run.

Your stated solution seems fine to me. It corresponds to a non-blocking receive.

from chan-signal.

Yes there was my misunderstanding. I didn't realize that the run thread will never finish and that thing2's lifetime is altered by moving to the new thread.

Thanks again for your help.

from chan-signal.