Glib closures and threads...

[Brett Kosinski <brettk frodo dyn gno org>]

I've been looking to doing bindings for GStreamer and GStreamer makes use
of threading.  This means that signal callbacks can be invoked from
multiple threads.  Now, I'm not sure how Perl handles the idea of multiple
threads making calls into a single interpreter (the opinion seems
mixed...).  However, I've managed to get a (VERY simple) threaded test
program written which does this exact thing, and it seems to work... :)

Now, in order to achieve this, I did the following:

1) in gperl_closure_new, I modified the set_marshal call and changed it to
   this:

   g_closure_set_meta_marshal ((GClosure*) closure,
                               aTHX,
                               gperl_closure_marshal);

   This causes the current perl interpreter to be passed into the callback
   as marshal data.

2) renamed gperl_closure_marshal to _gperl_closure_marshal and created
   gperl_closure_marshal as follows:

   static void
   gperl_closure_marshal(GClosure * closure,
                          GValue * return_value,
                          guint n_param_values,
                          const GValue * param_values,
                          gpointer invocation_hint,
                          gpointer marshal_data)
   {
           PERL_SET_CONTEXT(marshal_data);

           _gperl_closure_marshal(closure,
                                  return_value,
                                  n_param_values,
                                  param_values,
                                  invocation_hint,
                                  NULL);
   }



So, the effect is that the interpreter which is in use during the initial
call to create the closure is passed during the marshalling phase and is
used to execute the Perl closure.

Now, this seems to work fairly well (minus some other issues), but the
better question is, should this be possible?  Does Perl allow this sort of
thing?  If the answer is "yes", is this the correct solution?  It's *a*
solution, but it may not be the right one.

Brett.