Control of pipeline and g_main_loop in a daughter thread

[Wes Miller]

I have found my own solution to this problem, which I include below.  I don't
really understand why I had to do it this way, though, so I thought I'd ask
some "why's?"..

My application is a C++ dll/so that provides an intercom function between
two endpoint computers.  The user application attaches my dll and the
intercom runs till the user app tells it to stop.

Here is the general flow of things.  Sorry for the long explanation.

1. User app starts and attaches the dll and all the C extern-ed accessor
functions.

2. User asks the dll to create sender and receiver objects.  Note, this is
still in the user's thread (thread 0).  Pointers to the objects are
returned. 

3. User tells the objects to "run" (sender->run(), etc.)

4. Nearly identical run() methods create new threads that launch the
Receive() and Send() methods where all the real work gets done.  Receive()
and Send() each instantiate g_main_loops, build their pipelines, set them to
PLAYING and run() the g_main_loop.  Note, the pipelines and loops are
running in daughter threads (receiver thread and sender thread) NOT in
thread 0.

5. Eventually the user (app) calls DelSender() and DelReceiver() to destroy
the senders and receivers.  Note again, this IS done in thread 0.

Finally, we arrive at the problem.  It appears that issuing commands to send
an EOS, STOP the pipeline and quit() the g_main-Loop are ignored if they are
not issued in and by the daughter threads containing the loop and thread. 
Consequently, the pipeline and loop don't stop or go to odd states. 
Whatever oddness they perform, their threads don't stop and the whole thing
ends up issuing exceptions and core dumps.

My solution was to add a kill_thyself object variable to the sender and
receiver classes that can be set by thread 0 and seen by a once-a-second
timer attached to their g_main_loops.  When the timer see kill_thyself set
to true, it ends the pipeline, stops the loop and allow the daughter threads
to terminate cleanly.   Easy once you figure it out.  Yeah, right.

So the questions are:

Am I right that the stops and quits have to issued in the thread th==where
the pipeline and loop are running?

Why is this so.  What mechanism lets the thread 1, etc. objects ignore the
thread 0 calls to end them?

Or, what simple trick did I miss to get the attention of the loop and
pipeline.  I tried adding a wakeup for the context after the quit:
    
    g_main_loop_quit( m_loop );
    g_main_context_wakeup( g_main_loop_get_context( m_loop ));  // context
is "default"
     
which didn't work.

Should I have some method of associating the pipeline and loop in their
thread?  How does the pipeline know which main loop to attach to if there
are multiple loops?

Thanks,

Wes
 






--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Control-of-pipeline-and-g-main-loop-in-a-daughter-thread-tp4659382.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.