Lieber rosti,
lieber murphy,

Vielen lieben Dank für Eure Antworten.

@rosti
Ohne die problematische Version (d.h. unabhängig von einem GUI Toolkit) klappt alles wunderbar.

@murphy
Vielen lieben Dank für Deine Einschätzung und Idee. Ich hatte schon befürchtet, dass die Verwendung von threads in Perl/XS problematisch ist. Ich habe lustigerweise gestern Nacht noch bei der SDL Anbindung eine ganz ähnlichen Lösungsvorschlag gefunden, nur konnte ich den dazugehörigen Code nicht finden (siehe die Kommunikation hier)

Ganz ähnlich - allerdings eigtl. als simpler Workaround gedacht - funktioniert mein MPV::Simple::Pipe Module. Bei diesem läuft der ganze MPV Kram in einem eigenen mittels fork erstellten Prozess und völlig unabhängig vom GUI Teil. Der MPV Progress wartet auf Ereignisse und wertet Kommandos aus. Die Kommandos werden mittels Pipes vom GUI Teil an den Tcl Teil gesendet. Und die Ereignisse bring ich vom MPV Teil mittels eines geteilten Array (IPC2::Shareable) - Pipes wären zu langsam - in den GUI Prozess (Ich weiß, ich müsste eigtl. threads verwenden, aber mit diesen bin ich leider nicht recht glücklich geworden, weil ich beim Beenden des Programms immer einen Speicherzugriffsfehler erhalte). Tcl::Tk sucht jede Sekunde stets nach neuen Ereignissen und verarbeitet diese falls vorhanden ( $int->call("after", 1000, \&on_event) ). Ich weiß noch nicht, ob dieser Umweg über Perl effektiv genug ist (ich muss ja auf C Ebene noch das von wait_event zurückgegebene Event-Objekt in einen simplen Hash umwandeln, um zumindest annähernd die selbe Funktionalität wie mpv_set_wakeup_callback zu bieten). Allerdings würde mich aber auch die perfekte Lösung über C interessieren. Aber im Moment glaube ich, dass das für mich zu viel ist (für mich ist das Thema threads absolut neu...). Dennoch danke für Deine Idee...