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.edu
datri@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. --