After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 318116 - new state change patch
new state change patch
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal major
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-10-06 13:55 UTC by Wim Taymans
Modified: 2005-11-14 17:58 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
proposed patch (102.88 KB, patch)
2005-10-06 14:02 UTC, Wim Taymans 		none Details | Review
Improved patch (119.03 KB, patch)
2005-10-07 18:06 UTC, Wim Taymans 		none Details | Review
updated patch (99.14 KB, patch)
2005-10-08 10:06 UTC, Wim Taymans 		none Details | Review
updated patch (87.09 KB, patch)
2005-10-08 18:24 UTC, Wim Taymans 		none Details | Review
updated patch (90.64 KB, patch)
2005-10-10 08:41 UTC, Wim Taymans 		none Details | Review
Merged cosmetic changes, what's left is meat (64.77 KB, patch)
2005-10-10 14:11 UTC, Andy Wingo 		none Details | Review
Patch after merging static mutex waiting, recursive state lock (60.00 KB, patch)
2005-10-10 14:35 UTC, Andy Wingo 		none Details | Review

Description Wim Taymans 2005-10-06 13:55:00 UTC 
current state change design is rather awkward for the programmer. When doing a
state change to PLAYING, for example, the set_state() function stops performing
the state change as soon as it receives ASYNC. The programmer is then supposed
to perform the next state changes manually. GstPipeline also does a blocking 
wait to reach the final state change, which might be infinite in case of errors. 

Performing downward state changes might block indefinatly in a similar way and
require the application programmer to be prepared to handle ASYNC state changes.

GstBin and subclasses also don't post state change messages automatically after
completing the state change unless explicitly polled for with
gst_element_get_state() which is again blocking.

Various hacks exist to work around these problems in gstutils.c
(gst_element_set_state_async and gst_bin_watch_for_state_change which both spawn
threads).
Comment 1 Wim Taymans 2005-10-06 14:02:39 UTC 
Created attachment 53113 [details] [review]
proposed patch

this patch makes sure set_state() never blocks. It can return ASYNC and will
then asynchronously move itself to the target state at which point it will post
a message. A get_state() call blocks until the desired target state is reached.


The pending state in the get_state() call now returns the target value of the
state change. A get_state() can thus return current:READY pending:PLAYING if
the element is currently going from READY to PAUSED but was requested to go to
PLAYING after that.

Downward state changes also never block and will ignore all intermediate ASYNC
state changes up to the final state.

Error conditions are also handled better so that no lockups can occur when
trying to recover from an error.
Comment 2 Wim Taymans 2005-10-07 18:06:30 UTC 
Created attachment 53193 [details] [review]
Improved patch
Comment 3 Wim Taymans 2005-10-08 10:06:09 UTC 
Created attachment 53220 [details] [review]
updated patch
Comment 4 Wim Taymans 2005-10-08 18:24:53 UTC 
Created attachment 53233 [details] [review]
updated patch
Comment 5 Wim Taymans 2005-10-10 08:41:26 UTC 
Created attachment 53277 [details] [review]
updated patch
Comment 6 Andy Wingo 2005-10-10 14:11:17 UTC 
Created attachment 53293 [details] [review]
Merged cosmetic changes, what's left is meat
Comment 7 Andy Wingo 2005-10-10 14:35:49 UTC 
Created attachment 53294 [details] [review]
Patch after merging static mutex waiting, recursive state lock
Comment 8 Andy Wingo 2005-11-14 17:58:40 UTC 
Applied to CVS a long while ago