[gstreamer-bugs] [Bug 338827] [patch] gnomevfssrc should use async api to not block on network problems

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=338827

  GStreamer | gst-plugins-base | Ver: HEAD CVS





------- Comment #18 from René Stadler  2006-11-28 12:48 UTC -------
Looks to me like gnome-vfs (in its current form) is unsuitable for use by
gstreamer at all.  To recap the whole picture as it occurs to me:

gnomevfssrc as-is uses gnome_vfs_open_uri in ->start, which blocks and
therefore
possibly makes gst_element_set_state hang (very bad).  I provided a small patch
to move this blocking call into the streaming thread, so it will hang there
instead (slightly less bad).  James provided a better patch that does the
blocking calls in an extra thread, which should free applications from hanging
because they call innocent gstreamer functions (even less bad but still bad as
the threads are leaked until the operation times out).  These are workarounds
to ensure people don't lose data because their application locks up.

This would be cleanly solvable if the blocking calls of gnome-vfs were
cancellable.  It looks like that they are not.  There is something about
cancellation in the API, but only for use by methods (backends).  So no matter
what we come up with, the best possible solution involves leaking threads that
hang for a timeout of several minutes.

Therefore, we are left with the async API of gnome-vfs as the only opportunity
to get a clean solution.  However, the patch Stefan made to convert gnomevfssrc
over to the async calls does not work correctly.  The problem manifests itself
in these lines of code:

  /* wait for callback to be called */
  while (src->async_op_pending) {
    if (g_main_context_pending (NULL)) {
      g_main_context_iteration (NULL, FALSE);

Iterating a main context is only allowed from a single thread!  That's why
programs with a main loop become unstable with the patch.  gst-launch works
because it just polls the bus.  So no matter what, these lines have to go.  If
the thread just sleeps instead, everything should be fine as long as the
application iterates its default GMainContext.  Doing so is not a requirement
for using gstreamer at all - and that's the fundamental difference between
gstreamer and gnome-vfs.

Applying the patch (fixed in the way as described) would therefore mean that
any
application that uses gnomevfssrc _must_ run a GMainLoop for the default
GMainContext (or iterate the context in regular intervals in another way).  I
doubt making this a requirement is acceptable.

Looking for a solution in gnome-vfs might be the best idea.  Its assumption
that
the application iterates the default main context seems silly from the
gstreamer
point of view.  Then again, it's "gnome-vfs" and not "gvfs".


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email