Closures fundamentally broken

[mathijshenquet]

Closures right now are fundamentally broken:

fn main(){
    make_window();
    gtk::main();
}

fn make_window(){

    let mut window = gtk::Window::new(gtk::window_type::TopLevel).unwrap();
    let drawing_area = DrawingArea::new().unwrap();

    drawing_area.connect(signals::Draw::new(|cr| 
        drawing_area.get_allocated_area() //`drawing_area` is garbage
    ));

    window.add(drawing_area);
    window.show_all();
}

This is because rust only has stack closures for now. When make_window is finished and it's stack goes out of scope all referenced variables inside the callback become garbage.

I'll be able to fix this when rust-lang/rfcs#114 gets merged.

[mathijshenquet]

rust-lang/rfcs#151

also fixes this

[jeremyletang]

this should come soon: rust-lang/rust#14539

[mathijshenquet]

I don't think so, Unboxed closures seems to have had a major setback so now rfcs 151 is implemented, taking some uncontroversial/worked out ideas from Unboxed closures. At least, if i read https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-07-08.md correctly ;)

[pcwalton]

That is not true. Unboxed closures have not had a "major setback". I'm working on them as we speak.

[dubcanada]

What's the status of this now that rust-lang/rfcs#151 is fixed?

[gkoz]

Here's my take on closures/signals: https://gist.github.com/gkoz/52ae8de5370ba99d9795/9227b2a60e15cd3c00b824197cfc65d819bbeae4
GTK owns the closure after we box it and give the pointer to g_signal_connect_data as data.

            let closure: Box<Box<S::F>> = Box::new(closure);
            let closure_ptr     = transmute(closure);

            println!("connect closure {:?}", closure_ptr);

            glib::ffi::g_signal_connect_data(
                self.get_gobject(),
                c_signal_name.as_ptr(),
                Some(trampoline),
                closure_ptr,
                Some(transmute(destroy_closure)),
                0
            );

We also specify a destroy_data function that will take the ownership back and run the destructors.

extern fn destroy_closure(closure: *mut (), _: usize) {
    unsafe {
        println!("destroy closure {:?}", closure);
        let closure: Box<Box<FnMut()>> = transmute(closure);
        drop(closure);
    }
}

The weak link here is

        unsafe {
            let closure: Box<&mut FnMut($($arg_type),*) -> $ret_type> = transmute(closure);
            (*closure)($($arg_name),*)
        }

where we conjure a &mut reference to the closure in order to invoke it. I doubt it's safe...

[gkoz]

Actually we can just be conservative and use Fn closures: https://gist.github.com/gkoz/52ae8de5370ba99d9795
The example uses RefCell anyway, so it didn't even have to change. Transmuting a pointer to an aliased reference to Fn closure should be safe.

[GuillaumeGomez]

I think so too, casting should be safe. I did on other binding and it worked well. I don't see any reason why it couldn't here. It's a long time issue, it would be nice to fix it once and for all.

Do you want to do it ? I don't really have time recently so i won't do it before at least a week but maybe @jeremyletang will have it ?

But before that, we need to fix rgtk build ! I'll take a look this week-end.

[gkoz]

Maybe it should brew for a while more. There's another issue to tackle: the library has to translate between native GTK types and user-facing ones, possibly casting GdkEvent to an appropriate specific variant, converting between Gboolean and either bool or some event-specific enums (e.g. enum Propagate { Yes, No }).

[oakes]

Is this still a work in progress? I just ran into the problem today.

[gkoz]

My plan was to do the signals after the widgets are converted to the new model. We could probably change that. Today's draw signal debugging session has once again proved that a translation layer is required. Some of it is already in the tree.