jtw@lcs.mit.edu (John Wroclawski) (12/11/90)
(RISC/OS 4.51)
The flock() man page says
flock is emulated using the fcntl(2) mechanism and so file
locks obtained through the fcntl(2) and lockf(3) mechanisms
interact with those acquired via flock.
and the fcntl() man page says
File locks obtained through the fcntl mechanism interact
with those acquired via flock(2) and lockf(3).
but the lockf() man page says
File locks obtained through the lockf mechanism do not
interact in any way with those acquired via flock(2). They
do, however, work correctly with the locks claimed by
fcntl(2).
Unfortunately, I suspect the lockf() page is right, and the others
describe a good idea that didn't get done. Anyone know what's really
going on here?
-john
jtw@lcs.mit.edudatri@convex.com (Anthony A. Datri) (12/11/90)
> flock is emulated using the fcntl(2) mechanism and so file > locks obtained through the fcntl(2) and lockf(3) mechanisms > interact with those acquired via flock. If this is true, Mips is the first vendor that I've seen do it. One problem is that lockf/fcntl uses rpc.lockd, which I've not seen be solid on any platform. --