Hello all
Thanks Łukasz for your reply!
That explains the behavior. But then, shouldn't a thread also own the
thread function or will that lead to other issues?
Should the vapi binding be:
public static weak Thread create (owned ThreadFunc func, bool joinable)
throws ThreadError;
instdead of:
public static weak Thread create (ThreadFunc func, bool joinable) throws
ThreadError;
???
Then the closure handled by the thread will maybe not be freed too
early.
I really hope to clear all this because that looks like the only way to
pass some parameters to a threadfunction.
Regards,
Jörn
Am Donnerstag, den 14.01.2010, 11:06 +0100 schrieb Łukasz Pankowski:
> JM <interfl...@gmx.net> writes:
>
> > If I do the same thing with an Idle, the behavior is significantly
> > different, as the block data is not destroyed as soon as the run()
> > function is left. Why is that?
> >
> > Well working example:
> >
> > class HHH : Object {
> > public void run() {
> > string test = "test";
> > Idle.add(() => { print("in idle : %s \n", test); return
> > false;});
>
> if you look into glib-2.0.vapi Idle.add is declared as:
>
> public static uint add (owned SourceFunc function, [CCode (pos
> = 0.1)] int priority = Priority.DEFAULT_IDLE);
>
> so the add() is declared to own the function past to it, so the closure data
> will be kept alive
>
> > }
> >
> > public static MainLoop loop;
> >
> > public static int main() {
> > loop = new MainLoop(null, false);
> > var h = new HHH();
> > h.run();
> > h.run();
> > h.run();
> > h.run();
> > loop.run();
> > return 0;
> > }
> > }
> >
> > // valac closuretest.vala
_______________________________________________
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
