Messages in this thread |  | | Date | Sat, 26 Aug 2000 11:04:21 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH] thread wakeup fix for 2.4.0-test7 |
| |
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/
|  |