🚀 go-pugleaf

In article <dave.06zx@ccomnz.equinox.gen.nz> dave@ccomnz.equinox.gen.nz (David Eaves) writes:
> In article <mbs.3zdg@adastra.cvl.va.us> mbs@adastra.cvl.va.us (Michael B. Smith) writes:
> > ODU maintains an internal list of locks. It does not communicate with
> > a "lockd" on another host, if that's what you mean about networked
> > volumes, it's a single host solution.
>
> Bummer, I thought as much.  Can any solution be found that will support
> arbitrary networking software?  Does anyone know how Unix handles this?

Someone can write a "lockd", but such a thing doesn't currently exist
for the Amiga, AFAIK,

Sun has a locking specification for a locking daemong called "lockd". Again,
AFAIK, those specs are not public.

> Using AmigaDOS file/record locking could work with Amiga smart networking
> software (such as Envoy), but probably not with TCP/IP NFS because they
> wouldn't support the packets.  Correct?

Correct.

> I can only think of creating lock files beside the file to lock
> (possible?  Too slow?), or having some kind of replacable lockd back end
> that has the smarts for a particular networking software setup.  Any
> others?

Lock files have race conditions, especially across a network. To handle
it properly is much more difficult than you may think. The locking
scheme has to be at least bi-level, with a possibility for out-of-band
data.

Anyway, you've covered the two ways.

> > Flush() after each write I/O will take care of properly implemented
> > filesystems. It's certainly OK on 3.1 versions of FFS; I can't say
> > that I've tested with anything else.
> >
> > Flush() _will_ slow it down though.
>
> What say the programs offloaded the writing to a log handling task
> which owned the logfile and kept it open?

Well, I think that's a good idea. I suggested it in another message. ;)

> Would the file be readable by other processes (say if you just want to
> look at the logfile) while the lockd has it open for writing though?

It could be. It would take some care in how the file is set up.
> Or will the file be opened non-exclusive, and rely on everything being
> nice and using the lockd to avoid mixups.

Well, you have to do that regardless, to be able to read it. Either that,
or have a separate review window, which starts getting a bit complicated.
--
  //   Michael B. Smith
\X/    mbs@adastra.cvl.va.us