On Sat, 26 Aug 2000, Rusty Russell wrote:
>
> > Why do you call this a bug?
> >
> > Thread 1 still has the fd open (it's used by the poll()).
> >
> > The fact that thread 2 removed it from the fd table is immaterial.
>
> Your implementation disagrees with you: poll already returns POLLNVAL.
> With the patch it just returns it immediately, rather than returning
> it when/if it times out.
Tough. It's still because YOUR program is buggy. You closed a file
descriptor that was in use.
> Single Unix Specification also disagrees with you:
>
> The close() function will deallocate the file descriptor
> indicated by fildes. To deallocate means to make the file
> descriptor available for return by subsequent calls to open()
> or other functions that allocate file descriptors.
No. SuS agrees with me 100%.
The above is exactly what Linux does. The file descriptor is the _integer
number_allocated_to_that_process_ to describe the file. It has got NOTHING
to do with the file itself - think about dup() etc.
The _file_ is kept open by the poll(). The file descriptor is closed.
Think about mmap(): you can do
mmap(fd)
close(fd);
... the _file_ is still active through the mapping ...
and the mmap doesn't go away. Nobody expects the mmap() to go away just
because you closed the fd. It's still there - and in fact SuS _requires_
that it is still there.
The poll case is 100% the same.
As is, btw, read() and write() and just about everything else. Try it. Do
thread 0
read(fd, xxxxx) /* blocks */
close(fd);
... read continues to work ...
and the above is obviously the only "sane" semantics.
"fd" is just a handle. Once you've looked it up, it's not used any more.
Closing it after the fact is a non-issue - you just got rid of the handle
that we've already used.
> So we could sleep in close (forever, maybe) until the polls are
> finished if you prefer.
Nope.
Should close() wait until all memory mappings are gone too? Obviously not.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:18 EST