[gst-devel] Multi-threaded queueing locking issues
brentb at ridgerun.com
Thu Mar 22 23:06:37 CET 2001
Matt Howell wrote:
> the only case in which a thread would have to be killed (pthread cancel) is if
> it's blocked on a system call (e.g., non-blocking read). in the more common
> case of thread synchronization (where a thread is blocked because it called
> g_cond_wait()), you do not have to kill the thread.
> it seems the complication arises only in the blocking system call cases
> (blocking read, blocking write). if we wrote an i/o library for filters, we
> could manage this problem. these calls would be blocking as far as the
> filter is concerned, but, internally, do the i/o in a non-blocking fashion.
I like this idea.
Assuming potential unbounded blocking system calls are mostly limited to
open/read/write/close, this is a pretty elegant solution. It would be a little bit
annoying to have to replace calls to read() with calls to gst_read() (especially if
they happen to be burried in a non-gstreamer library), but the benefits may make it
Perhaps it could be said that unbounded blocking I/O calls just have no place in
quality software -- even if they are called from worker threads.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 237 bytes
Desc: Card for Brent Bradburn
More information about the gstreamer-devel