[Bug 701996] context: Still inconvenient to use and racy

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=701996
  GStreamer | gstreamer (core) | git

--- Comment #6 from Sebastian Dröge (slomo) <slomo at circular-chaos.org> 2013-09-13 09:28:41 UTC ---
Also not sure about the sticky event, we could also make the query
upstream/downstream instead. That way inside the pipeline everything could be
pull-based by queries instead of sometimes pull (query) and sometimes push
(event).

Instead of always setting all contexts on child elements of a bin, we could
also make this pull-based. An element asks for a context and the highest-level
bin (or app) that has such a context will then set it on that element only.

And bins would cache contexts that are posted on the bus by child elements, or
that were set on them by the application. The ones set by the application
should always be preferred and kept separate, the ones from the pipeline are
fallback and would be cleared when going to NULL. It is possible by the bins to
keep these separate because a need-context message will only cause the context
to be set on the sender of the message, not on any higher-level bin.

Only open problems with that are:
- setting application contexts on specific elements, how to distinguish between
these and ones set by a bin? Thread local storage usage while the need-context
message is sent?
- bin subclasses that want contexts set on them, how to distinguish there
between application and pipeline internal contexts? Basically the same problem.


Maybe setting a context as a result to the message should be done different
than setting an application context? Unfortunately we can't just add them to
the message as it will likely not be writable.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.