lkml.org 
[lkml]   [2005]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 7/7] uml: retry host close() on EINTR


    On Sun, 11 Sep 2005, Paolo Ornati wrote:
    >
    > So glibc doc is wrong here:

    Yes.

    > SUSV3:
    > -------------------------------------------------------------
    > If close() is interrupted by a signal that is to be caught, it shall
    > return -1 with errno set to [EINTR] and the state of fildes is
    > unspecified
    > -------------------------------------------------------------
    >
    > Unspecified! ;-)

    I don't know of any system where re-trying the close() is the right thing
    to do, but I guess they exist. I think the Linux behaviour of "hey, it's
    closed, live with it" is pretty universal - almost nobody ever tests the
    return value of close().

    Even the "careful" users that want to hear about IO errors have to really
    do an fsync(), so any IO errors should show up there. Of course, checking
    the return value of "close()" in addition to the fsync() is always a good
    idea anyway, and I suspect they do.

    In Linux, another thread may return with the same fd in open() even _long_
    before the close() that released it has even finished. The kernel releases
    the fd itself early, and then the rest (anything that could return EINTR -
    things like TCP linger stuff etc) is all done with just the "struct file".

    So retrying is really really wrong. And not just on Linux. I think this is
    true on _most_ if not all unix implementations out there.

    Linus
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-11-18 23:46    [W:4.087 / U:23.228 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site