Re: libseed-list bug with threads and closures?

[Jonatan Liljedahl <lijon kymatica com>]

timeout_add has:

        <parameter name="function"
                   transfer-ownership="none"
                   scope="notified"
                   closure="3"
                   destroy="4">
          <type name="SourceFunc" c:type="GSourceFunc"/>
        </parameter>

idle_add has:

        <parameter name="function"
                   transfer-ownership="none"
                   scope="notified"
                   closure="2"
                   destroy="3">
          <type name="SourceFunc" c:type="GSourceFunc"/>
        </parameter>

thread_create_full has:

        <parameter name="func"
                   transfer-ownership="none"
                   scope="call"
                   closure="1">
          <type name="ThreadFunc" c:type="GThreadFunc"/>
        </parameter>

What does the integer values for closure and destroy mean?

Also, if I play around and change stuff in the gir file, what is the 
necessary steps to try out the changes, do I need to compile it into a 
typelib file and replace the existing one?

/Jonatan

On 08/03/2010 04:17 AM, Alan Knowles wrote:
> Have a look at scope="call" - in and around that definition. It's probably also worth looking at timeout_add and see how the gir definition of that differs from thread_create.
>
>  From my nightmares with thread programming, where it segfaults, and even the backtraces tend to be of little use...
>
> usually more of a try and hope style fixing technique..
>
> Regards
> Alan
>
>
>   --- On 03/Aug/2010, Jonatan Liljedahl wrote:
> > On 08/03/2010 01:39 AM, Alan Knowles wrote:
> > > Avoid threads is normally the answer ;)
> >
> > If one wants life to be simple, yes ;)
> > But with todays multicore machines, threads is a must.
> >
> > > have you had a play with the transfer ownership stuff..
> > >
> > > = this is the thread_create_full first argument - it's tranfer none, which in theory
> > > means that the function is available for gc after the method is called.
> > >
> > >         <parameters>
> > >           <parameter name="func"
> > >                      transfer-ownership="none"
> > >                      scope="call"
> > >                      closure="1">
> > >             <type name="ThreadFunc" c:type="GThreadFunc"/>
> > >           </parameter>
> >
> > Yes, but I think JSValueProtect() is called on it somewhere..
> > Also, storing it in a global variable didn't help:
> >
> > var f;
> > ...
> > GLib.thread_create_full(f=function() { ...
> >
> > Also it fails in different ways each time, so it's clearly a memory-bug
> > of some kind. Sometimes it even says that variables are missing in the
> > thread-function or idle-function, before it crashes.
> >
> > /Jonatan
> >
> > > Regards
> > > Alan
> > >
> > >    --- On 02/Aug/2010, Jonatan Liljedahl wrote:
> > > > Any ideas on this? I'm stuck.. Hoping someone with more insight in
> > > > closures and gobject-introspection might help.
> > > >
> > > > /Jonatan
> > > >
> > > > On 07/28/2010 04:06 PM, Jonatan Liljedahl wrote:
> > > > > This simple code crashes (output and stacktrace at the end of this
> > > > > mail). I don't see why it shouldn't work. GLib.idle_add() is the
> > > > > recommended way to defer stuff from a thread to the mainloop and I've
> > > > > used it several times in C code.
> > > > >
> > > > > Seems to be a problem with closures, threads and the garbage collector?
> > > > >
> > > > > /////////// thread_bugs.js ////////////
> > > > > var Gtk = imports.gi.Gtk;
> > > > > Gtk.init(0,0);
> > > > >
> > > > > var w = new Gtk.Window({border_width: 20});
> > > > > var b = new Gtk.Button({label: "Foo"});
> > > > > w.add(b);
> > > > > w.show_all();
> > > > >
> > > > > b.signal.clicked.connect(function() {
> > > > > print("Clicked");
> > > > > GLib.thread_create_full(function() {
> > > > > print("Thread start");
> > > > > var i=0;
> > > > > var x=1.3;
> > > > > for(i=0;i<9999999;i++) {
> > > > > x *= 1.000004;
> > > > > };
> > > > > print(x);
> > > > > print("Dispatch to mainloop");
> > > > > GLib.idle_add(GLib.PRIORITY_DEFAULT_IDLE,function() {
> > > > > print("In mainloop");
> > > > > b.label = "Bar"+x;
> > > > > return false;
> > > > > });
> > > > > },null,0,true);
> > > > > });
> > > > >
> > > > > Gtk.main();
> > > > > //////////// EOF /////////////
> > > > >
> > > > > Clicked
> > > > >
> > > > > ** (seed:2184): WARNING **: ArgumentError - probably due to incorrect
> > > > > gir file (which may be fixed upstream) argument 2 must not be null for
> > > > > function: thread_create_full
> > > > >
> > > > > [New Thread 0xb57d8b70 (LWP 2188)]
> > > > > Thread start
> > > > > 3.05975143636762e+17
> > > > > Dispatch to mainloop
> > > > > In mainloop
> > > > >
> > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > 0x00cdbd12 in ?? () from /usr/lib/libwebkit-1.0.so.2
> > > > > (gdb) bt
> > > > > #0 0x00cdbd12 in ?? () from /usr/lib/libwebkit-1.0.so.2
> > > > > #1 0x00cdc8a4 in ?? () from /usr/lib/libwebkit-1.0.so.2
> > > > > #2 0x00cdc905 in ?? () from /usr/lib/libwebkit-1.0.so.2
> > > > > #3 0x00cdd845 in ?? () from /usr/lib/libwebkit-1.0.so.2
> > > > > #4 0x00cde4f0 in ?? () from /usr/lib/libwebkit-1.0.so.2
> > > > > #5 0x00be63b3 in JSGlobalContextRelease () from /usr/lib/libwebkit-1.0.so.2
> > > > > #6 0x00137bb6 in seed_handle_closure (cif=0x81ccc00, result=0xbfffec38,
> > > > > args=0xbfffebd0, userdata=0x81cb7e8) at seed-closure.c:290
> > > > > #7 0x003aa316 in ?? () from /usr/lib/libffi.so.5
> > > > > #8 0x003aa6fa in ?? () from /usr/lib/libffi.so.5
> > > > > #9 0x00301151 in ?? () from /lib/libglib-2.0.so.0
> > > > > #10 0x00303165 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
> > > > > #11 0x00306f88 in ?? () from /lib/libglib-2.0.so.0
> > > > > #12 0x003074c7 in g_main_loop_run () from /lib/libglib-2.0.so.0
> > > > > #13 0x0132c3c9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
> > > > > #14 0x003aa63f in ffi_call_SYSV () from /usr/lib/libffi.so.5
> > > > > #15 0x003aa46f in ffi_call () from /usr/lib/libffi.so.5
> > > > > #16 0x0039c799 in g_function_info_invoke ()
> > > > > from /usr/lib/libgirepository-1.0.so.0
> > > > > #17 0x0013bb4a in seed_gobject_method_invoked (ctx=0xb636e098,
> > > > > function=0xb5f3be80, this_object=0xb6338ac0, argumentCount=0,
> > > > > arguments=0xbffff0d0, exception=0xbffff11c) at seed-engine.c:656
> > > > > #18 0x00be20be in ?? () from /usr/lib/libwebkit-1.0.so.2
> > > > > ---Type<return>   to continue, or q<return>   to quit---
> > > > > #19 0x00c28f1a in ?? () from /usr/lib/libwebkit-1.0.so.2
> > > > > #20 0x02614236 in ?? ()
> > > > > #21 0x00c3a7ce in ?? () from /usr/lib/libwebkit-1.0.so.2
> > > > > #22 0x00cf5b66 in ?? () from /usr/lib/libwebkit-1.0.so.2
> > > > > #23 0x00bdc4a9 in JSEvaluateScript () from /usr/lib/libwebkit-1.0.so.2
> > > > > #24 0x0013860c in seed_evaluate (ctx=0xb67a2e24, s=0x80579c0, this=0x0)
> > > > > at seed-api.c:279
> > > > > #25 0x08048f01 in seed_exec (filename=0xbffff64c "thread_bugs.js") at
> > > > > main.c:95
> > > > > #26 0x08049134 in main (argc=2, argv=0xbffff4c4) at main.c:161
> > _______________________________________________
> > libseed-list mailing list
> > libseed-list gnome org
> > http://mail.gnome.org/mailman/listinfo/libseed-list
>
> _______________________________________________
> libseed-list mailing list
> libseed-list gnome org
> http://mail.gnome.org/mailman/listinfo/libseed-list