Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Rob.McConnell@Zarlink.Com wrote:
> Johannes Stezenbach <js@linuxtv.org> wrote on 06/10/2004 16:37:07:
> > Rob.McConnell@Zarlink.Com wrote:
> > >
> > > 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.
> 
> Does this differ from what you were describing above?

Hm, I must confess I haven't tried to close a file descriptor
while anothter thread is blocking in read/write/ioctl. Maybe
the usage count is temporarily incremented during the blocking.
I assumed the blocking ioctl would return with e.g. EBADF, but
probably I am wrong on this.

Your EXIT ioctl is still odd. No other driver that I know of
does this.

Regards,
Johannes




Home | Main Index | Thread Index