[gst-devel] Multi-threaded queueing locking issues

[Brent Bradburn]

Erik Walthinsen wrote:

> On Tue, 20 Mar 2001, Matt Howell wrote:
>
> > i agree.  you shouldn't have to use the timed-wait stuff in this case.  also,
> > you don't want to use system kill/signal to fix thread scheduling.
> >
> > i was thinking something like this: (pseudo-code :)
> > gstpad.c::queue_get() - to the while loop, add
> >   // somehow, get pendingState
> >   if (pendingState == PAUSED) { GST_UNLOCK(lock); return NULL; }
> >
> > gstpad.c::queue_chain() - to the while loop, add the same thing
> >   if (pendingState == PAUSED) { GST_UNLOCK(lock); return NULL; }
> >
> > gstpad.c::change_state() - add
> >   if (GST_STATE_PENDING (element) == GST_STATE_PAUSED)
> >   {
> >     GST_LOCK(queue);
> >     signal(emptycond); // wake up waiting queue_get()'s, if any
> >     signal(fullcond); // wake up waiting queue_chain()'s, if any
> >     GST_UNLOCK(queue);
> >   }
> >
> > gstscheduler.c::chain_wrapper() - i'm not sure it's necessary, but probably add:
> >
> >   if (pendingState == PAUSED) break;  // stop calling pad_pull()'s,
> >
> > there may be other places in gstscheduler.c code to do similar.
> >
> > thoughts?
>
> The problem is that the above solution only works for queues, and makes
> them intimately aware of the threads and vice versa.  The queues aren't
> the only things that are going to be blocking.  Anything that attaches to
> a file descriptor (file, network, etc.) could also block, and we have to
> come up with some way of interrupting them as well.
>
> I'm not sure how one would go about interrupting a blocking read, or the
> best way to set it up to time out.  I'd like to find a way (even if it's
> element-specific in the form of a special interuption callback) to
> interrupt them explicitely, rather than making them spin in a timeout
> loop.  That forces them to use select, and other messy stuff.
>

I agree, it would be nice to allow elements to call blocking I/O functions (instead
of using poll).  It's more elegant and probably more general.  However, I'm not sure
yet how to cleanly close such elements if they end up blocking indefinitely.  There
should be a standard computer science answer to this question.  I imagine its an
issue for many projects.  It may be as simple as pthread_cancel().