[gstreamer-bugs] [Bug 501239] Add support for "realtime thread pools"

[GStreamer (bugzilla.gnome.org) <bug...@bu...>]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=501239

  GStreamer | gstreamer (core) | Ver: git

Olivier Crete (Tester) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |te...@te...




------- Comment #10 from Olivier Crete (Tester)  2009-05-07 22:24 UTC -------
The part about get/set priority in your patch doesn't seem useful, since it
seems that g_thread_set_priority doesn't change the policy (and priority is
ignored in SCHED_OTHER on Linux at least).. Since GLib doesn't abstract it and
its so system specific, leaving it to custom callbacks is probably better..

I'm also not convinced of the utility of the GstTaskPool, it would be easier to
just be able to control callback functions in the GstTask (like GstPad), so we
could have callbacks for start thread and stop thread, etc.. and the default
implementation would call g_thread_pool_push/join, but then I could have custom
implementations that just do pthread_create/join (and then I would have the
pthread_t so I can change its priority later). I guess having a custom
GstTaskPool subclass does the same (but is kind of more complicated since I
have to subclass a GObject).. 

And anyway, since GstBaseAudioSink/Src uses g_thread_create/join directly,
playing around with GstTask isn't enough to have proper realtime scheduling.

That said, I think I can do all I want by just listening for the ENTER message
and do a pthread_self() and then I get the thread for this pad/task. And using
the LEAVE message to restore the thread to its original state. I guess internal
threads should also emit it (I'm thinking of baseaudio src/sink here).

And then when I discover that I need RT, I can iterate over the pads/elements
following their links (using gst_pad_iterate_internal_links & gst_pad_get_peer)
and for each one check if I have a message/task for this one and set the
properties I want on the thread. Getting the task from the current thread
doesn't seem to useful then, since I would already have a list of
pad/elem->tasks/threads associations (from the messages). Also, since a task is
not always linked to a GThread, getting the Task is not so useful.

Also, looking at the caps is not enough.. for example if I have
udpsrc->jb->sink then only the caps of the tasks after the jitterbuffer have
caps that can tell me its audio, not the caps before.. So using notify::caps
isn't so useful.

I guess we can also forget the probe event for now. I'd prefer getting the
STREAM_STATUS messages asap so we can try playing around with them.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=501239.