[linux-dvb] Re: More V4 Video API Q's

[Johannes Stezenbach <js@linuxtv.org>]

Rob.McConnell@Zarlink.Com wrote:
> Holger Waechtler wrote:
> > after a little more thinking I believe that the following would be the
> > correct implementation:
> >
> > * open()
> > * start decoder threads
> > (... wait for stop command from GUI...)
> > * send stop signal to threads
> > * call pthread_cancel()
> > * pthread_join()
> > * close().
> >
> > Since blocking read/write and ioctl calls are defined by POSIX as
> > cancellation points this should work just fine without any extra support
> > in the API. After passing non-cancellation points the decoder threads
> > should call pthread_testcancel().
> 
> I call pthread_cancel from the main thread to cancel the thread that is
> blocked waiting for the DVB_VIDEO_GET_EVENT ioctl to return.  This returns
> immediately as the blocking ioctl is a cancellation point.  I then call
> pthread_join to tidy up any loose ends and obtain the return code.  I then
> check the return code (PTHREAD_CANCELED) to see how the thread was
> cancelled.
> 
> This works very well and is certainly something that application folk
> should make a note of (if they haven't already).

The problem with pthread_cancel() is that the thread itself cannot
directly do cleanup, so if it has any resources allocated you have
to deallocate them elsewhere. There is pthread_cleanup_push() etc.,
but I've never tried if that works as expected with linuxthreads.

This can get really messy if your thread e.g. receives the DVB event
and then pushes an application event into an event queue which is
protected by a mutex (somewhere deep inside a library), and just
then gets cancelled while it holds the semaphore...
Maybe PTHREAD_CANCEL_DEFERRED prevents this problem but you better
check carefully.

Also, the BUGS section in the pthread_cancel() man page says that
blocking syscalls should be cancellation points, but aren't (but
return with EINTR due to linuxthread implementation side effects).


Johannes