[Bug 766898] player: Add a message queue API in addition to the signals

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=766898

--- Comment #19 from Stephan Hesse <tchakabam at gmail.com> ---
The reason why it is done like it is currently is I wasn't expecting anyone to
actually store that bus reference. That's also why we're not increasing the
ref-count when we return it. It wasn't a transferrable thing as I was thinking
how it would be used. You would always have to own a player ref to access it. I
would also recommend that in your multi-thread scenario, the threads share the
player instance rather than just the bus instance (why would you have to do
latter thing?). Obviously, the current design is error-prone because it allows
to do so.

So what we could do ensure that only player ref is shared, is just adding
methods on GstPlayer API that allow to pop from the bus, instead of returning a
reference to the bus. And keep the bus ref private.

Because ref-counted or not, in your scenario, if the player was destroyed and
someone kept the reference to the bus, that would not be sane. Adding
ref-counting everytime someone "gets" the bus ref also would really require us
to validate that the ref-count on that is zero before we destroy the player?

Therefore we should probably rather encapsulate all the bus methods needed by
API users. So wrap the pop call into a gst_player instance method. That will
avoid to be able using the bus if the instance is gone in the first place, and
per se rather require to use the player instance ref only.

It is also much simpler to keep one type of ref-counted object around for the
users of the API (the player instance), rather than several (player instance
and bus).

Does that make sense to you?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.