Re: [Vala] Threads and closures problem

[JM <interflug1 gmx net>]

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 <interflug1 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