lkml.org 
[lkml]   [2002]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: close return value (was Re: [ANNOUNCE] Ext3 vs Reiserfs benchmarks)
    From
    On Tue, Jul 16, 2002 at 09:10:49PM -0600, Thunder from the hill wrote:
    > Hi,
    >
    > On Tue, 16 Jul 2002, Elladan wrote:
    > > > Thread 2 shouldn't be able to reuse a currently open fd. This application
    > > > design is seriously broken.
    >
    > Okay, again. It's about doing a second close() in case the first one fails
    > with EAGAIN. If we have to do it again, the filehandle is not closed, and
    > if the filehandle is not closed, the kernel knows that, and if the kernel
    > knows that the filehandle is still open, it won't get reassigned. Problem
    > gone.

    This is case 2, "Close is guaranteed to leave the file open on error."

    In this case, all applications are required to reissue close commands
    upon certain errors, or leak a file descriptor. This would be a well
    defined behavior, though perhaps error prone.

    However, note that this is manifestly different from case 1, "Close is
    guaranteed to close the file the first time." If the system behaves via
    case 1, closing the handle again is broken as the example illustrated.

    The worst, of course, would be undefined behavior for close. In this
    case, the application effectively can't do the right thing without
    extreme measures.

    -J
    -
    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: 2005-03-22 13:27    [W:3.024 / U:0.132 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site