Re: Preliminary patch for flock (just for discussion)

[Paolo Bonzini]

>> But lockf unlike flock does not support shared locks, which are very
>> useful.  I can take care of implementing it in terms of fcntl when
>> Richard's patch goes in.
> 
> Very good point. You can write flock() in terms of fcntl()?

Yes, simply like this:

  struct flock fl;
  fl.l_start = 0;
  fl.l_len = 0;
  fl.l_whence = SEEK_SET;

  type = operation & (LOCK_SH | LOCK_EX | LOCK_UN);
  if (type & (type - 1))
    {
      errno = EINVAL;
      return -1;
    }

  if (type == LOCK_SH)
    fl.l_type = F_RDLCK;
  else if (type == LOCK_EX)
    fl.l_type = F_WRLCK;
  else if (type == LOCK_UN)
    fl.l_type = F_UNLCK;

  if (operation & LOCK_NB)
    {
      int rc = fcntl (fd, F_SETLK, &fl);
      if (rc == -1 && errno == EACCES)
        errno = EAGAIN;
      return rc;
    }
  else
    return fcntl (fd, F_SETLKW, &fl);

There is still the difference that

"This interface [fcntl] follows the completely stupid semantics of
System V and IEEE Std 1003.1-1988 (``POSIX.1'') that require that all
locks associated with a file for a given process are removed when any
file descriptor for that file is closed by that process.  Another minor
semantic problem with this interface is that locks are not inherited by
a child process created using the fork(2) function.  The flock(2)
interface has much more rational last close semantics and allows locks
to be inherited by child processes."

This obviously would not apply to the fcntl-based emulation of flock,
which would be as broken.

> Also, in glibc we have code for lockf() in terms of fcntl.
> The native OS support of these three APIs is that
>   - fcntl with F_SETLK is supported on all Unix platforms.

F_SETLKW too?

>   - lockf is supported on all Unix platforms except Cygwin, BeOS.
>   - flock is supported on all Unix platforms except AIX, HP-UX, Solaris, BeOS.
> 
> So with the two replacements for flock() and lockf() in place, and with
> an implementation of fcntl F_SETLK for mingw, we will get all three APIs
> supported in gnulib across all platforms!

Two APIs are already one too much. :-P

>> I don't think having an fcntl wrapper in gnulib makes any sense).
> 
> Why not? It does not need to support all possible control commands, only those
> that we chose to provide.

I don't want to make Windows support in gnulib look like the little
brother of cygwin (except that it cannot do as well because it works
with the MSVCRT runtime).

Paolo