lkml.org 
[lkml]   [2008]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: file offset corruption on 32-bit machines?
    Bryan Henderson wrote:
    > The easiest way to imagine a program not doing locking and being useful
    > anyway (as long as the kernel is thread-safe) is to use the same arguments
    > you use for the kernel doing it: there's a higher level user responsible
    > for locking. The code in question doesn't guarantee that user writes all
    > its stuff to the right place, but at least it guarantees that that user's
    > lack of locking doesn't screw some other user of the file. It does that
    > by ensuring it never seeks to a place the user doesn't own and that no two
    > separate users ever access the file at the same time.
    >
    > I'd even like to accomodate the poor user trying to debug the broken
    > locking in his application. He sees the file getting corrupted and
    > immediately thinks, "what if my thread serialization isn't working right?"
    > But he notices that the corruption isn't consistent with that hypothesis.
    > He knows he was working with only the beginning and the end of the file
    > and the corruption happened in the middle. So he wastes a week
    > considering other hypotheses, including a kernel bug, until someone points
    > out a paragraph in the lseek() man page that says contrary to all Unix
    > convention, that particular function and system call is not thread-safe,
    > and it doesn't necessarily seek to the place mentioned in its argument.

    I think that argument is the strongest yet. Wasted debugging time due
    to totally surprising and hardly justifiable kernel behaviour. Strace
    / GDB on the application shows a trace which doesn't relate at all to
    the unexpected file changes.

    There is also POSIX specification:

    http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_09.html

    "All functions defined by this volume of IEEE Std 1003.1-2001 shall
    be thread-safe, except that the following functions need not be
    thread-safe."

    [List which does not include lseek(), therefore lseek() shall be
    thread-safe. Same for read() and write().]

    Docs for HP-UX and AIX say the same as POSIX about thread-safety.

    -- Jamie


    \
     
     \ /
      Last update: 2008-04-16 11:43    [W:2.606 / U:0.360 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site