Re: [PATCH 1/6] libfshelp_rlock

[Samuel Thibault]

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