[gstreamer-bugs] [Bug 505770] gst_element_get_state() should unblock if element posts an error

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #16 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2010-04-05 23:59:30 UTC ---
> I'm not sure why adding a return value would complicate things; as a bonus it
> also allows code to safely test for whether the behaviour has changed and it
> can safely use get_state()

It can safely use get_state() in any case, unless you can think of a case where
a program might actually want to block forever waiting for something that won't
be happening.

Adding a new return value would complicate things because:

 - 99% of the code out there doesn't even handle the
   existing values correctly

 - the actual problem is that most people who use this
   function don't understand the details of the state
   change mechanism, the various failure scenarios, how
   things work and/or are supposed to work, and whether
   or not they should be using get_state() here or if it's safe.
   Adding yet another return value won't help

 - adding another return value risks breaking existing
   code that actually tries to handle the return values;
   of course you could argue that that code isn't correct
   from the start, but that wouldn't not particularly helpful
   IMHO (and then we could just argue that code using
   get_state() incorrectly is broken and we don't need this
   fix at all).


Maybe we should just deprecate _get_state() and replace it with a bunch of new,
better functions, such as gst_pipeline_wait_for_preroll (pipeline, &error),
gst_pipeline_wait_for_preroll_with_timeout (pipeline, &error, -1);
gst_element_get_states (&cur_state, &pending_state); or something like that.

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