[gst-devel] Multi-threaded queueing locking issues

[Brent Bradburn]

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
worthwhile.

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...
Name: brentb.vcf
Type: text/x-vcard
Size: 237 bytes
Desc: Card for Brent Bradburn
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20010322/94e71875/attachment.vcf>