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

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

     \ /
      Last update: 2005-03-22 12:38    [W:0.023 / U:39.780 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site