Re: Some comments about GVFS

[Alexander Larsson <alexl redhat com>]

On Tue, 2007-05-08 at 11:19 +0200, Benjamin Otte wrote:
> (short reply here, so you can continue your interesting discussion,
> I'll answer in more detail when I'm back from UDS)
> 
> On 5/8/07, Alexander Larsson <alexl redhat com> wrote:
> > On Tue, 2007-05-08 at 03:33 -0500, Hans Petter Jansson wrote:
> >
> > I know Benjamin mentioned multiple contexts was needed for gstreamer
> > integration. It would be nice to hear some details about this
> >
> GStreamer runs the pipeline in seperate threads. While reads are
> typically scheduled from just one thread, any thread could potentially
> initiate actions on the stream. An example would be seeking: seek
> events are dispatched from the thread doing the seek - this could be
> the main thread for a user event or any other thread if a downstream
> element needs to seek. So the event would cancel the read operation
> and do the seek. This would wake up the read thread noticing it was
> interrupted and reschedule the read.

So, you would have one of gstreamers threads doing the read operation,
and this would be using async i/o and a custom glib mainloop on that
thread. Then say the main thread on user input decides to seek in the
stream, this seek call on the main thread will cancel the async read
operation running in the gstreamer thread and schedule a new seek
operation there instead. Is this a correct example?

I'm still not sure why gstreamer needs to run its own mainloop in its
thread though. If its async, then it should be able to use the default
mainloop. Is it because there is no guarantee of the default mainloop
running always?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a short-sighted guitar-strumming assassin in drag. She's a foxy insomniac 
detective with a knack for trouble. They fight crime!