XS_MPV__Simple__xs_set_wakeup_callback (my_perl=0x555555953260, ...)
[download]

You'll need to explain to me how these extra threads are created and what they do, and what happens to the main perl thread while the callback is taking place - is it suspended, or is it off busily doing its own thing?

Dave.

Dear Dave, Yes, the perl interpreters are not the same:

# perl thread
(gdb) p my_perl
$1 = (PerlInterpreter *) 0xb
(...)
 dSP;
(gdb) p my_perl
$7 = (PerlInterpreter *) 0x555555953260
(...)
# mpv thread:
(gdb) p my_perl
$2 = (PerlInterpreter *) 0x1
(...)
dSP;
(gdb) p my_perl
$3 = (PerlInterpreter *) 0x0
[download]

Regarding the creation of the extra threads: To be honest, I don't know how they are created and what with the main perl thread happens. This is managed by libmpv and I don't know and understand the code very well.. The error seems to occur in mpv_initialize from mpv-player/client.c, which calls mp_wakeup_core from mpv-player/playloop.c that triggers an event from the saved dispatch queue. mpv/misc/dispatch.c describes it as follows: "A dispatch queue lets other threads run callbacks in a target thread. The target thread is the thread which calls mp_dispatch_queue_process()." This is here mp_dispatch_interrupt which was called in mp_wakeup_core. So I think the target thread is created in mpv_create with the following lines:

pthread_t thread;
    if (pthread_create(&thread, NULL, core_thread, mpctx) != 0) {
        ctx->clients->have_terminator = true; // avoid blocking
        mpv_terminate_destroy(ctx);
        mp_destroy(mpctx);
        return NULL;
}
[download]

core_thread() consists of the following lines:

static void *core_thread(void *p)
{
    struct MPContext *mpctx = p;

    mpthread_set_name("mpv core");

    while (!mpctx->initialized && mpctx->stop_play != PT_QUIT)
        mp_idle(mpctx);

    if (mpctx->initialized)
        mp_play_files(mpctx);

    // This actually waits until all clients are gone before actually
    // destroying mpctx. Actual destruction is done by whatever destro
+ys
    // the last mpv_handle.
    mp_shutdown_clients(mpctx);

    return NULL;
}
[download]

I don't know whether this is helpful. Perhaps the task is a number too big for me because I have no clue regarding threads? Nevertheless thank you very much for all your help and patience..

Max

PS.: I also don't understand why one time the callback is called in the perl thread? Perhaps because of the following line in mpv_set_wakeup_callback?

if (ctx->wakeup_cb)
ctx->wakeup_cb(ctx->wakeup_cb_ctx);
[download]

Ok, I found https://www.perlmonks.org/?node_id=867652 and without studying the thread in depth, I tried the following and it seems to work so far:
first ein deleteted #define PERL_NO_GET_CONTEXT in the beginning of my Simple.xs file. then I created a set_ctx function

void set_ctx()
{
    dTHX;
    mine = Perl_get_context;
}
(...)
MODULE = MPV::Simple        PACKAGE = MPV::Simple
(...)
void
_set_context(ctx)
    MPV::Simple ctx
    CODE:
    set_ctx();
[download]

and called it in the constructor in Simple.pm

sub new {
    my ($class) = shift;
    my $obj = $class->xs_create();
    
    bless $obj;
    $obj->_set_context();
    return $obj;
}
[download]

Last I set Perl_Context in callp instead of dTHX:

void callp( SV* data)
{
    //dTHX;
    PERL_SET_CONTEXT(mine);
    {
    dMY_CXT;
    dSP;
    
    ENTER; SAVETMPS; 
    PUSHMARK(SP);
    
    PUTBACK;
    
    perl_call_sv(MY_CXT.callback,G_DISCARD|G_NOARGS);
    SPAGAIN;
    
    PUTBACK;FREETMPS;LEAVE;
    }
}
[download]

Does that make any sense? Or is it ugly and bad? To be honest, I don't really understand the linked thread :-) And I am a little bit worried because of deleting PERL_NO_GET_CONTEXT.. I have to do further tests, whether the binding now works as expected.. Max

UPDATE: Unfortunately this doesn't work, too. Sometimes it seems to work and the video is shown. But in other cases there is again the segfault or the thread is closed too early.

Hello everybody, I have given up to create the binding to mpv_set_wakeup_callback. Instead I created an own pure Perl Module, which makes it possible to run the mpv player in another fork process beside an existing event loop (see MPV::Simple::Pipe on github). It is not perfect, but the best that I can. Nevertheless I wanted to explain my status quo. Perhaps it is useful for some other person, who is confronted with the same problem and is more experienced to solve the problem. The explained segfault problem could be solved by cloning perl in the c callback handler as follows (@dave_the_m: I think this is the solution you explained, but I didn't understand first?):

void callp( )
{
    int new_perl = 0;
    
    dTHX;
    if ( my_perl != NULL )
         printf ("my_perl == %ul\n", my_perl);
      else
      {
         printf ("my_perl was NULL\n");
         PERL_SET_CONTEXT(mine);
         perl_for_cb = perl_clone(mine, CLONEf_KEEP_PTR_TABLE);
         PERL_SET_CONTEXT(perl_for_cb);
         
         // The following seems not necessary
         //CLONE_PARAMS clone_param; clone_param.stashes = NULL; clone
+_param.flags = 0; clone_param.proto_perl = perl_for_cb;
         
         new_perl = 1;
      } 
    
    dSP;
    SV* callback = get_sv("MPV::Simple::callback",0);
    SV* data = get_sv("MPV::Simple::callback_data",0);
    
    ENTER; SAVETMPS; 
    PUSHMARK(SP);
    
    EXTEND(SP,1);
    PUSHs(sv_2mortal(newSVsv(data)));
    
    PUTBACK;
    
    perl_call_sv(callback,G_DISCARD);
    SPAGAIN;
    
    PUTBACK;FREETMPS;LEAVE;
    
    // I don't know whether this is important
    if ( new_perl ) {
        perl_free(my_perl);
        PERL_SET_CONTEXT(mine);
    }
}
[download]

The callback data and the reference to the perl function was saved in a global perl variable in Simple.pm, before the xs function is called (this was similarly effectiv as the complex MY_CTX stuff). The XS function is:

void
_xs_set_wakeup_callback(MPV::Simple ctx, SV* callback)
    CODE:
    {
    void (*callp_ptr)(void*);
    callp_ptr = callp;
    mpv_set_wakeup_callback(ctx,callp_ptr,NULL);
    }
[download]

Unfortunately in more complex examples there are sometimes new segfaults, sometimes it works smoothly. I think the problem is the complex structure of the thread for event handling in mpv. If someone has a further idea to implement this all in perl, it would be great. I am still interested in learning and understanding XS more... Thanks all, Max

The explained segfault problem could be solved by cloning perl in the c callback handler as follows

Not really. The problem is that the interpreter you're trying to clone is owned by another thread. That thread might be actively executing, causing the state of that interpreter structure (and all the data hanging off it) to be changing at the same time that a second thread is trying to clone it.

It all depends on what the original perl thread is doing. If it just calls a 'start event loop' function in mpv which suspends the thread and lets mpv's own threads take over to do all the active work and callbacks, then you could just set my_perl to point to the original perl's interpeter and let the mpv thread update that. If multiple mpv threads can call callbacks simultaneously, then you'd need either to have a lock so that only one thread can use the interpreter at a time, or you'd need to create enough perl threads such that there is a big enough pool of interpreters to be borrowed by all active mpv threads. Of course with multiple interpreters you'd have the issue of only one interprter getting updated, not necessarily the one you want.

Or you could have some sort of queue system whereby mpv callbacks just put requests into queue which are popped and processed by one or more perl threads.

But without having some details of what the mpv library does and how, this is mainly speculation.

Dave.