Sorry to bump up such an old thread, but I think it's important. On Sat, 2005-05-14 at 15:45 +0200, Matthias Bläsing wrote:
====
use utf8;
use GStreamer -init;
my $thread1 = GStreamer::Thread->new("thread1");
my $thread2 = GStreamer::Thread->new("thread2");
my $audiosink = GStreamer::ElementFactory->make("alsasink", "alsa");
my $source = GStreamer::ElementFactory->make("filesrc", "file");
my $mad = GStreamer::ElementFactory->make("mad", "mad");
my $queue = GStreamer::ElementFactory->make("queue", "queue");
GStreamer::Element::link_many($source, $mad, $queue);
$thread1->add_many($source, $mad, $queue);
$source->set("location", "/home/mblaesing/musik/musik/Pur -
Abenteuerland.mp3");
$queue->link($audiosink);
$thread2->add($audiosink);
$thread1->set_state("playing");
$thread2->set_state("playing");
GStreamer->main();
====
When running this small example it just segfaults (when calling the
mainloop) and I don't now why. Am I right if I asume, that perl messes
with the thread handling?
It looks like this was due to a Glib bug I'm about to commit a fix for. It basically occured whenever a log message was initiated by a thread: Glib's default log handler would be invoked in that thread's context, and then call Perl_form, which accesses a memory pool that is "thread-local". So without setting perl's thread context to a sane one first, it always segfaults right there. For those of you who don't want to wait for anoncvs to catch up, the patch is also attached. With the fix applied, the above example works nearly unaltered for me. (I replaced "mad" with "spider" and changed the filename.) -- Bye, -Torsten
Attachment:
log.patch
Description: Text Data