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

[Rob.McConnell@Zarlink.Com]

Hi Again,

Johannes Stezenbach <js@linuxtv.org> wrote on 06/10/2004 19:33:04:

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

When I checked the O'Reilly LDD2 book it mentioned that the usage count in
the file struct is incremented for dup() and fork() syscalls.  I assumed
that it would probably be the case for clone() as well.

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

I don't particularly think its elegant either.  However, if you need to
ensure a driver is closed down immediately then it does the job.  Take for
example a typicl DTV app that opens the frontend, demux and A/V decoders.
If the app closes, then the video and audio drivers should be closed first,
then the demux and then the frontend to ensure no artefacts, etc.  If the
app has a thread that is blocked on say the DVB_VIDEO_GET_EVENT ioctl, then
conceivably the video device may not be closed down before the other
devices and you may get strange results.

I wonder if other drivers out there in Linux have had to face the same
problem and if so how do they overcome it cleanly?

Just a few thoughts for bedtime....

Rob ; )