lkml.org 
[lkml]   [2000]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.130 / U:0.180 seconds]
©2003-2014 Jasper Spaans. Advertise on this site