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

[Holger Waechtler <holger@qanu.de>]

Johannes Stezenbach wrote:

> 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.
>  
It worked for me.

> 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.
>  
this would be another solution.

> 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).
>  
how should they return elsewise?

Holger