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

[Holger Waechtler <holger@qanu.de>]

Rob.McConnell@Zarlink.Com wrote:

> Hi Johannes,
>
> Johannes Stezenbach <js@linuxtv.org> wrote on 06/10/2004 16:37:07:
>
>  
> > Rob.McConnell@Zarlink.Com wrote:
> >    
> > > Johannes Stezenbach <js@linuxtv.org> wrote on 05/10/2004 23:42:39:
> > >      
> > > > On Mon, Sep 27, 2004 at 03:29:56PM +0000, Rob.McConnell@Zarlink.Com
> > > >        
> > > > > 3) I would like to see a DVB_VIDEO_EXIT or DVB_VIDEO_DEINIT ioctl
> > > > >          
> that
>  
> > > > > unblocks all processes sleeping on wait queues so that they can be
> > > > >          
> > > woken up
> > >      
> > > > > prior to the driver being closed.  For example,  if you have
> > > > >          
> multiple
>  
> > > > > threads that access the video device and one is blocked on the
> > > > > DVB_VIDEO_GET_EVENT ioctl, then when the user-space application
> > > > >          
> calls
>  
> > > > > "close", the actual close function will NOT be called until all
> > > > >          
> threads
>  
> > > > > have exited.  By calling DVB_VIDEO_EXIT or DVB_VIDEO_DEINIT first,
> > > > >          
> all
>  
> > > > > threads can be terminated in a controlled fashion and the close
> > > > >          
> syscall
>  
> > > can
> > >      
> > > > > then complete.  I have used this method on current drivers and
> > > > >          
> works
>  
> > > very
> > >      
> > > > > well indeed.  Maybe we should reflect this ioctl in other drivers
> > > > >          
> as
>  
> > > well?
> > >      
> > > > That sounds totally bogus to me. If a thread blocking in some ioctl
> > > > prevents you from doing a close() in another thread (which could then
> > > > wake up the other thread) then our or your locking is broken.
> > > > Or maybe I didn't understand what you mean...
> > > >        
> > > The close() syscall will not actually call the code (release method) to
> > > close the device down until the usage count in the "file" structure
> > >      
> reaches
>  
> > > 0.  This means if you either opened the device multiple times or called
> > > clone()/fork() on the fd, then the usage count will be incremented.
> > >      
> Now in
>  
> > > you have called clone() (by calling "pthread_create" say), then the
> > >      
> usage
>  
> > > count will have been incremented.  If the thread is blocking on an
> > >      
> event,
>  
> > > then a close() syscall in the parent process will not evoke the release
> > > method until the thread has exited.
> > >      
> > Threads share file descriptors, there is no increment in use count
> > after pthread_create() like it is after fork(). IOW, the
> > CLONE_FILES flag is passed to clone() when a new thread is
> > created. So you should either avoid opening the device twice,
> > or use poll() with some other fd you can use to signal your
> > thread to exit. Either way, it is a problem of your app and
> > your proposed API extension is the wrong way to solve it.
> >    
> Well I've just knocked up a noddy kernel driver that blocks on a read
> waiting for data from a write syscall.  The complementary user app opens up
> this devices, calls "pthread_create" to create a new thread that will
> simply do a read on the new device and display the data.  The main
> thread/process just pauses 1s after calling pthread_create and then calls
> "close()".  It then pauses another couple of seconds before exiting
> completely.
>
> What I've found is that when we issue the close() syscall, the release
> method is not called immediately.  It is only when the main thread/process
> exits that the release method is called.
>  
Have you tried to send a signal to the blocking thread? This can in any 
case get catched & processed in the ioctl handler.

Holger