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

[GStreamer (bugzilla.gnome.org)]

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

           Summary: context: Still inconvenient to use and racy
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: slomo at circular-chaos.org
         QAContact: gstreamer-bugs at lists.freedesktop.org
                CC: vjaquez at igalia.com
     GNOME version: ---


Right now GstContext depends on a combination of queries, events, messages,
propagation of information in bins and application interaction to work.

This is unfortunately a bit racy still, as e.g. if two elements request a
context at the same time, it could happen that nothing gets them the context
and they both create their own. To mitigate this, it is required by the
application to handle the have-context messages in a sync bus handler (but
can't set the context there on the bin because that can lead to deadlocks). So
also need to do that from the async bus handler. But this is not solving the
race at all.


Also the requirement that the application does stuff is not ideal. Many
applications just don't care, the elements should figure out automatically what
to do. So ideally the bins would already catch the have-context and
need-context messages and propagate things upwards and downwards as required.
However this is easily deadlock-prone again. And automatic handling of these
messages inside the bin doesn't allow the application to have complete control
over the contexts (if it wants to do so), e.g. having a different device
context for two parts of a pipeline.


So to summarize:

- context handling is still racy if two elements want/create a context at the
same time
- applications often don't care about contexts, but have to handle them in a
generic way... deferring that to the bins removes control from the application
(if it wants to), so would need a way to override and intercept this (from the
application, inside bins you have GstBin::handle_message and
GstElement::post_message).

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