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

[Rob.McConnell@Zarlink.Com]

Hi Johannes,

Some more interesting things to report...

Johannes Stezenbach <js@linuxtv.org> wrote on 07/10/2004 11:47:18:

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

Yes, I've just added it to my demo app and it works fine.

Now the question is should the corresponding pthread_cleanup_pop be placed
at the same level as the push or at a higher level to ensure the cleanup
handler is removed properly.

e.g.  pthread_cleanup_push(cleanup_handler, NULL);

      ioctl(DVB_VIDEO_GET_EVENT, ......);      [BLOCKED]

      pthread_cleanup_pop(0);

Here if another thread/process calls pthread_cancel to cancel this thread,
then it will exit immediately before it gets to pthread_cleanup_pop.  The
man page recommends keeping the push/pop calls in the same function, but
I'm not convinced of this.

Any comments?

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

pthreads are created with PTHREAD_CANCEL_DEFERRED by default, so doing this
shouldn't be a problem as long as a cleanup handler is installed.

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

Yeah, they just return immediately.

Cheers,

Rob : )