nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Truncated Email.


From: Robert Elz
Subject: Re: [Nmh-workers] Truncated Email.
Date: Mon, 07 Mar 2016 07:45:57 +0700

    Date:        Sun, 6 Mar 2016 14:39:31 -0800
    From:        Lyndon Nerenberg <address@hidden>
    Message-ID:  <address@hidden>

  | Is this an instance of fcntl's completely braindead locking behaviour?

It is, when used for the kind of application that nmh wants (and most other
uses) - I suspect however it was designed for applications where the use
model was shared access to a large file (multiple applications reading and
writing it concurrently - like databases) with the objective being preventing
those processes from stepping on each other, and the expected use pattern
being something like

        /* calculate and work out what change needs making */
        fcntl(lock appropriate region);
        read()/write() as needed to make the update (perhaps unlocking and
                        returning to re-do calcs of data had changed while
                        waiting the lock)
        fcntl(unlock)

and the weird unlock semantics were an attempt to prevent bugs in applications
from keeping regions of the file locked by accident for longer than necessary
(almost anything other than simple i/o that touches the file causes unlock).
It is also intended to be mandatory - any i/o to the region affected should
be blocked while the lock is in place, not only other lock attempts.

For that kind of application it works fine, and flock() is useless (since
it is all or nothing, it would unnecessarily block irrelevant accesses as
well as ones that need blocking, and being advisory only - only other flock()
attempts get blocked - does nothing to preserve the integrity of the file.)

For other applications, fcntl is indeed hopeless, and flock a much better
fit, for applications that want to co-operate with each other for more
drastic file operations.   It is unfortunate that Sys V got only fcntl()
style locking, and BSD only flock() (initially at least) so that users
in general came to see them as competing alternatives, which they never
really should have been.   It is even worse that anyone would dream of
implementing one using the other - that's just brain dead, they are too
different.

kre 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]