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

[GStreamer (bugzilla.gnome.org)]

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




------- Comment #7 from Wim Taymans  2009-04-24 17:26 UTC -------
Comment #5 and Comment #6: A slightly different use case here but certainly
something that we also should support.

The patch in Comment #4 also allows for setting the thread priority but at a
different moment, when the thread is first entered (_ENTER) or when the thread
is created (_CREATED). See also the example stream-status.c. It's slighly
harder to use because you have to catch the messages and then figure out if the
thread is part of the pipeline you want to change the priority of. The
advantage is that you can raise the priority before dataflow happens and while
autoplugging is busy constructing stuff. Likewise you can lower the priority
again when the thread is DESTROYED.

The messages also have the added benefit that you can also handle internal
threads created by an element (the threads to write to an audio device come to
mind)

The GstTaskPool idea is a bit more involved. If you want to do serious realtime
threading you also likely want to have a watchdog thread to kill any stray
threads in order to not lock up your system. This is something that a realtime
threadpool can do in the background. The taskpool is also usefull if you need
threads with specific stacksizes or other features that are not configurable
after the thread is created and running.

Configuring the priorities with an event seems to be the easiest but least
flexible way to do things. You would likely send the event after the pipeline
is autoplugged up to the sink, in which case dataflow already happened at the
normal priority and you missed your chance to raise the priority earlier.

Also an event requires you to run the entire src -> sink path with the same
priority. For RTP, for example, it could make sense to only run the receiver
parts with a high priority up to the jitterbuffers in order to not lose
packets, but after that regular scheduling might work just fine (or do this
just for the video part and run the complete audio part at higher priority).

This is just to give you a bit more background info for what this patch wanted
to support. I'll add your event based patch too, likely by making a new core
EVENT_PRIORITY type. It also needs to be more configurable as it currently just
sets the priority to one of the realtime variants.


-- 
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.