Re: Glib closures and threads...

["muppet" <scott asofyet org>]

Brett Kosinski said:
> 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?

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.


if you meant the latter, then you can have multiple interpreters calling Glib
functions.  i don't really see many problems with that, unless each
interpreter is on its own processor thread, and then you'll run into locking
issues again.


> Now, this seems to work fairly well (minus some other issues),

anything of interest, or related to your threading hacks?

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


-- 
muppet <scott at asofyet dot org>