lkml.org 
[lkml]   [2002]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] zerocopy NFS updated
    David S. Miller wrote:
    > I'm not advocating more locking in read() -- there's no need, and it is
    > quite important that it is fast! But I would very much appreciate an
    > understanding of the rules that relate reading, writing and truncating
    > processes. How much ordering & atomicity can I depend on? Anything at all?
    >
    > Basically none it appears :-)
    >
    > If you need to depend upon a consistent snapshot of what some other
    > thread writes into a file, you must have some locking protocol to use
    > to synchronize with that other thread.

    Darn, I was hoping to avoid system calls.
    Perhaps it's good fortune that futexes just arrived :-)

    In some ways, it seems entirely reasonable for truncate() to behave as
    if it were writing zeros. That is, after all, what you see there if the
    file is expanded later with a hole.

    I wonder if it is reasonable to depend on that: -- i.e. I'll only ever
    see zeros, not say random bytes, or ones or something. I'm sure that's
    so with the current kernel, and probably all of them ever (except for
    bugs) but I wonder whether it's ok to rely on that.

    -- Jamie
    -
    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:25    [W:5.266 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site