bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Preliminary patch for flock (just for discussion)


From: Richard W.M. Jones
Subject: Re: Preliminary patch for flock (just for discussion)
Date: Fri, 3 Oct 2008 10:19:27 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Fri, Oct 03, 2008 at 02:25:42AM +0200, Bruno Haible wrote:
> Richard W.M. Jones wrote:
> > here is a preliminary patch for flock support for Windows.
> 
> Three comments.
> 
> * About the function. Why flock() and not lockf()?
>   There are three APIs for locking:
>     - lockf in POSIX [1],
>     - fcntl in POSIX [2],
>     - flock in BSD and glibc [3][4].
> 
>   According to the gnulib doc (doc/posix-functions/lockf.texi,
>   doc/glibc-functions/flock.texi) lockf is supported on a wider range of
>   platforms than flock.
> 
>   Also, the man pages say that the relation between the POSIX locks and
>   flock are unspecified. Which means, flock can easily fail to detect that
>   a file is already locked in the POSIX sense.
> 
>   Therefore, why not forget about flock() and implement lockf() instead?

My motivation for this patch is to port gdbm to the MinGW / Windows
environment.  Gdbm can use flock or fcntl (not lockf), and given that
(a) flock is very simple and (b) sqlite implements what are
essentially flock semantics, I went with that.

> * About the platforms.
> 
>   Before doing a mingw port, IMO it is reasonable to cover the Unix platforms,
>   i.e. provide the support for Solaris, AIX, HP-UX in the flock() case or
>   for Cygwin in the lockf() case.
> 
> * About the code.
>   You don't need to test whether the platform is VER_PLATFORM_WIN32_NT or
>   not. Windows 95/98/ME is not a porting target any more. In fact, the
>   doc on msdn.microsoft.com does not mention any more which function were
>   supported on Windows 95/98/ME and which were not.

I didn't realize that Windows 95/98 were no longer a target.  That
does change things.  On Windows 95/98 you have to use LockFile which
is very limited -- it supports only mandatory exclusive locks on file
ranges.

Windows NT supports LockFileEx which can do mandatory exclusive or
shared locks on file ranges.

So it might make sense to implement fcntl-locking[1].  But
implementing fcntl's F_GETLK is going to be very hard ...  It returns
the pid of the process holding a lock.  As far as I can tell there is
no way to implement this in Windows.

Anyway, I'm open to suggestions -- continue with the simple flock
implementation, removing support for older Windows platforms and
adding some other Unix platforms, or try an fcntl impl.

Rich.

[1] Even though fcntl is advisory -- in practice mandatory vs advisory
locks probably doesn't make a difference because we are always talking
about cooperating libraries and programs.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v




reply via email to

[Prev in Thread] Current Thread [Next in Thread]