Re: 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.
>
> whose threads?  processor threads created by glib via the wrapped GStreamer
> library?  or perl threads?

The first... GStreamer has it's own threading library (cothreads) which is
uses to create threads.  I've wrapped these things so you can create
GStreamer threads within Perl.

> if you mean the former, then you can have multiple processor threads vying for
> the same perl interpreter object.  sounds a little hairy, like you'd need to
> do some serious locking, but it doesn't sound impossible.
>
> be forewarned: there is very little static data in the bindings, but what's
> there is not locked.  the most dangerous are probably the class/package
> mapping hash tables in GObject.xs and friends, which are not locked like their
> C counterparts.

Ahh, I see what you mean.  This could definitely be a problem, although an
easy one to fix.

> > Now, this seems to work fairly well (minus some other issues),
>
> anything of interest, or related to your threading hacks?

Related to my hacks, AFAICT... the Glib module itself is working like a
charm.  Great work, BTW!

> > 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.
>
> i have no real opinion on this matter.  what you described sounds reasonable,
> but it lacks context.  can you give more information, and an example
> application to show where you're going?

Well, the gist of the example application is it sets up a media pipeline
to run in it's own thread (GStreamer provides it's own threading
infrastructure), and hooks a callback into the pipeline for when the end
of the stream is reached using the regular signal mechanism in Glib.  The
thread is then launched and the main app goes to sleep until the thread
terminates.  This means that the callback that is hooked in will be
triggered and executed in the new thread, rather than the original one.

Now, there are two problems here.  The first is, as you described, the
global datastructures in the Glib module.  This should be fixed, simply
because if someone uses Perl's built in threading stuff (which, AFAIK, is
stable in 5.8.0), there will be concurrency issues.  This is easy,
though.

The second involves the question of whether a single interpreter can be
used from multiple threads simultaneously.  This I don't know the answer
to... in fact, it may be a better question to pose on one of the Perl
mailing lists.  However, there are indications that this is possible with
5.8.0 (see perlguts - "Should I do anything special if I call perl from
multiple threads?").

Of course, in the end, it may be that I won't make the GStreamer threading
stuff available in Perl, forcing the user to use Perl threads instead if
they want a multithreaded application.  But, if I can make the GStreamer
stuff available, it'd be nice.

Brett.