Olaf was wondering about flock being reimplemented over this new implementation. It's actually a tricky question. I believe there are two issues:
Are lockf/fcntl/flock supposed to interact or be independent? On Linux, lockf and fcntl interact, and flock is independent from the two others. On BSD however, they all interact with each other. I believe it is thus safe for us to have only one implementation. The only difference between flock and fcntl/lockf, AFAIU, is that the former is per opened file, and thus get inherited through forks, and the latters are per process, and thus don't get inherited through forks. The implementation proposed by Neil is per opened file, which is thus not what we want in the end for fcntl/lockf. It happens that some people are trying to propose a variant of fcntl that would be per opened file. All in all, I'd suggest the following: - let's take the Neal implementation for now. It doesn't provide the right semantic (per opened file instead of per-process), but it should be fine enough for our current use. tdb at least should be happy, since it is happy with our current whole-file lock which is per-opened file. - let's make GETLK however return ENOSYS: we can't fill the l_pid, and this is not worse than what we have ATM. - let's already put the process token in the new RPC API. Setting it to non-NULL from the client will mean "I want a per-process lock", and for now let's return ENOSYS in that case. - later, we'll implement proper per-process locks, by using the token as an identifier of the process. - we'll then be able to implement GETLK, and in case a per-open lock was taken, we'll put -1 in l_pid, like BSD does. - when per-opened file record locks get standardized, we can trivially implement it. Samuel
