blob: 8047c7ca16d823b25b54e83e4f64d3df92524f26 [file] [log] [blame]
Some notes on use of pthreads in GStreamer
First off, pthreads are HARD. Remember that.
1) How I learned to debug glibc and pthreads and add debug code to it.
You have to trick your GStreamer test app in running against a modified
I used Red Hat 7.3, downloaded the .src.rpm, installed it, applied the
patches included, and ran
./configure --prefix=/home/thomas/cvs --with-add-ons
make install
After quite some time this left me with recompiled libc and libpthread
libraries in /home/thomas/cvs/lib, as well as a new
Now you need to use this new ld loader to run your app,
preferably from inside of gdb so you can tell what's going on when it
You can use to call your binaries: .libs/thread1
to run the thread1 program with the new glibc.
If this is a GStreamer app, chances are it might not find some libraries
it needs that you could safely use from /usr/lib (like, zlib and popt).
Also, you want it to run in gdb, so this is my full line:
LD_LIBRARY_PATH=/usr/lib /home/thomas/cvs/lib/ \
/usr/bin/gdb .libs/thread1
At this point you can start adding debug code to the pthreads implementation
in your glibc source tree. Just change, re-run make install, and restart
the test app in gdb.
Helpful --gst-mask is 0x00200100 to get thread info and scheduling info
(with mem alloc from cothreads)
2) What GStreamer does with pthreads.
Apps create a thread with gst_thread_new. This just allocates the GstThread
structure without actually doing much with it.
When a thread goes from NULL to READY, the gst_thread_change_state function
creates the actual pthread.
- we lock the thread->lock mutex
- we create attributes for the pthread
- by default the pthread is JOINABLE
- we ask the thread's scheduler for a preferred stack size and location
(FIXME: if the scheduler doesn't return one, what do we do ?)
- we create the pthread with the given attributes
- the pthread id is stored in thread->thread_id
- the created pthread starts executing gst_thread_main_loop (thread)
- the change_state function does a g_cond_wait
- this means it unlocks the mutex, waits until thread->cond is set
(which happens in gst_thread_main_loop),
then relocks the mutex and resumes execution
From the point of view of the created pthread, here's what happens.
gst_thread_main_loop (thread) gets called
- the thread's mutex gets locked
- the thread's scheduler's policy gets examined
- the scheduler gets set up (invokes the scheduler object's setup method)
FIXME: what are the prereqs of this _setup method ?
- basic and fast scheduler both call do_cothread_context_init
- basic: this calls cothread_context_init
- cothread_context_init
- fast: this calls cothread_create (NULL, 0, NULL, NULL))