Re: [PATCH] thread wakeup fix for 2.4.0-test7

From: Linus Torvalds (
Date: Sat Aug 26 2000 - 13:04:21 EST

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

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


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


Should close() wait until all memory mappings are gone too? Obviously not.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:18 EST