lockf and the SVID, (Was "Re: Wanted: lockf system call source")

[P. D. Guthrie]

[ Oh line eater, line eater, wherefor art thou? ]

In article <2264 at sdcsvax.UCSD.EDU> hutch at sdcsvax.UUCP (Jim Hutchison) writes:
>Not that H-P is at fault for following the mighty SVID, but why require
>that the file-descriptor is open for write to do a write lock?  Wouldn't
>any open file-descriptor do?
>I can see a reasonable scenario where a program reading a file might not
>want the record it is looking at changed under it.  This would seem pretty
>common when dealing with multiple processes accessing a database.  What
>gives?

Well, in a situation like this, you would most likely have the process
doing the writing provide advisory read locking.  The situation you
describe would seem to suggest cooperating programs to some extent
(multiple processes accessing a database).  In this case you simply have
the writing process turn on write and read locks before writing.  In
this way your read process would fail, not the write process (more
important in most applications), and have to re-read - getting the new
data.  This does the same thing in a slightly more elegent manner.

I see your point, but this could lead to not-well-thought-out database
design.  I'm not too sure what SVID says about read locks on a write-
only file descriptor, but the POSIX book does not have any restrictions.
The SysVr3 design (obviously this should conform to SVID) is also based
on the same /usr/group specs.  The original discussion about the HP
implementation is quite clearly non-standard.  Perhaps someone from HP
knows if this was an implementation dependant decision, or a clearly
thought out plan.

-- 

Paul Guthrie					We come in peace,
ihnp4!ihdev!pdg					We bring BEER!