🚀 go-pugleaf

Excerpts from internet.other.info-andrew: 13-Nov-92 Question about AMDS
message.. Neil Weisenfeld@ucbvax.B (1023)

> Our AMDS system is set up so that a number of machines may deliver the
> same message.  Is there any sort of locking system used to keep them
> from stepping on each other's toes?   I'm writing a biff program and it
> seems to suffer from two ailments:

> 1. Sometimes the user gets informed about a message twice since its
> modification time changes twice.

> 2. Sometimes the biff program starts scanning the message for headers
> as the message is being written and subsequently winds up hitting EOF
> before finding all of the headers.


> Now I know that I could solve #1 by keying off of the filename and not
> checking the same file twice, but how about #2?  Is there some lock
> mechanism for the Mailbox directory or the message files, or is it just 
> a free for all?

Sure, there's a locking mechanism.  You can solve both problems by using it.

The delivery protocol for new messages being created in ~userid/Mailbox/
is as follows.  The delivery agent (the producer) follows one protocol,
and the reader (the consumer) follows another.

Delivery agent/producer:
    (d1) invent a filename (generally with an ams_genid() call); call it FOO
    (d2) create ~userid/Mailbox/FOO with open(), getting a file
    descriptor (``fd'')
    (d3) flock(fd) with an exclusive lock.
        -- on failure, close the file, leaving a zero-length file;
        restart at step (d1), creating a new file name.
    (d4) write the contents of the file
    (d5) close the file, releasing the lock in the process.

Reader/consumer:
For each file in the ~/Mailbox directory (here named FOO):
    (r1) open the ~/Mailbox/FOO file with open(), getting a file
    descriptor (``fd'')
    (r2) flock(fd) with an exclusive lock.
        -- on failure, close the file and skip processing FOO.
    (r3) get file status with fstat(fd) or whatever, to check the file
    length and age.
        -- if zero-length and under 20 minutes old, close the file and
        skip processing FOO.
        -- else if zero-length, ignore it as an orphan.
    (r4) read the file and unlink it from ~/Mailbox when done.

At at least one point I believed that this would be an adequate
interlock model.  The down-side is that if (r1+r2) interleaves between
(d2) and (d3), the delivery process leaves an orphaned zero-length file
that has to be reaped somehow; hence the heuristic measure as the last
clause of (r3).

An amds-biff process would be excellent, and could simply follow the
same protocol as does the reader, except for unlinking the file in step
(r4).  I'd argue that both your problems arise when your biff checks new
files between (d2) and (d4), and that you can dodge the problem with the
flock() protocol.

		Craig