Closures fundamentally broken about gtk

[StephanvanSchaik]

I have a proposition to possibly fix this, the problem however is that it would require some additional wrapping to get it to work. So the current problem with closures seems to be that they are unable to live long enough to actually be called whenever a signal gets triggered. This happens because they get passed to the C interface, but the Rust binding keeps owning them. Eventually, they will get cleaned up from the stack, after the function where they were created at returns. Then, when Glib and GTK+ actually need them, they end up invoking a closure with garbage data.

To fix this, we would have to claim ownership of the closures within the binding, and store them somewhere safe. What I am basically proposing is to keep track of signal mappings for GObjects in a HashMap or something similar, and add a dispatch method to actually invoke the associated callbacks. This would look something like this example:

use std::collections::HashMap;

struct Signals {
    signals: HashMap<String, Box<FnMut() -> ()>>
}

impl Signals {
    fn new() -> Signals {
        Signals { signals: HashMap::new() }
    }

    /* It may be possible to do this with lifetimes as well. */
    fn connect(&mut self, name: String, callback: Box<FnMut() -> ()>) {
        self.signals.insert(name, callback);
    }

    fn dispatch(&mut self, name: &String) {
        let callback = match self.signals.get_mut(name) {
            Some(callback) => callback,
            _ => return
        };

        callback();
    }
}

fn do_connect(signals: &mut Signals) {
    let index = 42;

    let name = "foo".to_string();
    signals.connect(name, Box::new(move || println!("{}", index)));
}

fn main() {
    let mut signals = Signals::new();
    do_connect(&mut signals);

    let name = "foo".to_string();
    signals.dispatch(&name);
}

Then once this is in place, we can implement callbacks for the actual signals that will in turn use this signal map to dispatch the signals to their respective callbacks. So yes, the unfortunate part, is that we are essentially implementing our own signal system on top of an existing one. To further clarify what I mean: the low-level callbacks would simply be very generic ones that take all the arguments, and dispatch them into our signal system, and that we can either enable (by connecting them) or disable (by disconnecting them).

However, if we do it properly, we only have to connect the signals that have to be, i.e. if the a signal is not in use, it should not be in use in the low-level layer either.

Then there should be one final issue, and that is getting the callbacks to be generic enough that they can be used for the different events. This should be doable with either enums or traits, but this idea still requires some more polishing.

[gkoz]

Owning is not a big issue, we can even let the lib own them like in this example: https://gist.github.com/gkoz/52ae8de5370ba99d9795
BTW I believe the handlers can't generally be FnMut because they need to be reentrant.
Supporting different numbers and sets of arguments and converting them between foreign and native types is tough.

[gkoz]

Maybe that signal-specific glue will just have to be done by hand similarly to the method calls.

[StephanvanSchaik]

I think they can be either Fn or FnMut, depending on whether you want the changes to the environment to be persistent or not (in the sense that if you don't want to use the environment of a previous call, then FnMut is useless).

[StephanvanSchaik]

I've been looking at your example, and I see how you could have the library own the closure with proper deletion by passing a callback to clean it up. I have to admit, that I still had to read about what transmute actually does, and now that I understand that, I also understand why your code works :).

Ownership was one of my concerns because the original code in upstream takes a mutable reference to a closure, instead of actually moving the closure to the function, but that issue is solved with what you are currently doing.

I think it makes sense to implement the signals by hand for the moment being, I am willing to help with that, and then later on, attempt to generalise it. Especially, since we can then observe the various cases that have to be supported.

[GuillaumeGomez]

@StephanvanSchaik: That'd be very nice ! Any help is appreciated ^^

[gkoz]

I think they can be either Fn or FnMut, depending on whether you want the changes to the environment to be persistent or not.

It's conceivable that a signal handler can end up causing the same signal to be processed in a recursive manner (example). I believe such use isn't compatible with FnMut, which expects its mutable borrows to be unique therefore isn't reentrant.

[gkoz]

As there is some momentum for fixing the closures, I'll try to integrate the example from #16 (comment) into the tree without breaking existing signals support.

[gkoz]

There's actually an even stricter constraint to what we can give to the lib. It's Fn + 'static i.e. the closure wouldn't be allowed to capture any non-static references at all (we still can move values into it though).
The approach of owning the closures ourselves would be more flexible but it's not clear it'd gain us anything in practice. It could probably be done incrementally afterwards. One more practical problem with that is that rc::Weak isn't going to be stable in Rust 1.0.
One more alternative is letting each object (e.g. a button) own its signal handlers storage and disconnect them on destruction. That would probably need rc::Weak too.

[gkoz]

The proposed solution for review: #33

[gkoz]

The initial implementation has been merged, we need to migrate all of the signals into this module now and then remove the old infrastructure.

[gkoz]

cc @oakes

[gkoz]

So the closures aren't broken any more. They're just not very convenient now... :)