Re: libseed-list bug with threads and closures?

[Jonatan Liljedahl <lijon kymatica com>]

From the JSCore API docs:

"JS_EXPORT JSContextGroupRef JSContextGroupCreate()

A JSContextGroup associates JavaScript contexts with one another. 
Contexts in the same group may share and exchange JavaScript objects. 
Sharing and/or exchanging JavaScript objects between contexts in 
different groups will produce undefined behavior. When objects from the 
same context group are used in multiple threads, explicit 
synchronization is required."

Of course script-side variables need to be explicitly locked if used by 
more than one thread, but perhaps something need to have locks around it 
also on the C-side?

/Jonatan

On 08/03/2010 09:12 PM, Jonatan Liljedahl wrote:
> Commenting out JSGlobalContextRelease ((JSGlobalContextRef) ctx) at the
> end of seed_handle_closure() in seed-closure.c makes the problem "go
> away", but of course leaves the ctx in the land of forgotten pointers...
>
> So, is the problem that the ctx is released before the thread exits, or
> that it's release before any nested functions inside the thread finishes
> (like callbacks passed to idle_add or timeout_add), or both?
>
> If I understand correctly, the ctx *should* be alive as long as the
> thread exists, since the ctx is created before the javascript thread
> function is called and released after it has returned. But! I still get
> a crash on JSGlobalContextRelease() with just a simple print() or "var x
> = 2*34" in the thread. (no nested callbacks involved)
>
> Also, I guess this means that seed_handle_closure() is called from the
> thread and not from main? That brings the question, is
> seed_handle_closure() threadsafe?
>
> /Jonatan
>
>
> On 08/02/2010 03:15 PM, 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 /////////////