Problem getting flock with timeout to work

Corinna Vinschen corinna-cygwin@cygwin.com
Thu Mar 12 22:17:00 GMT 2009


On Mar 12 17:44, Robert Klemme wrote:
> The second flock does not start the command as I expect it to be.
> 
> I am referring to the man page of flock which says this about option -w:
> 
> Fail  (with an exit code of 1) if the lock cannot be acquired within
> seconds seconds.  Decimal fractional values are allowed.
> 
> So, since the second flock obviously cannot obtain the lock in time, I
> would have expected it to fail and not execute the command given.
> This is at least a documentation issue as flock's behavior and
> documentation do not match IMHO.

This scenario (your first testcase) works fine with Cygwin 1.7 with my
fix from a couple of hours ago.  I missed the fact that BSD flock lock
semantic allows to set both lock types (LOCK_SH/LOCK_EX) regardless of
the read/write mode in which the file has been opened, in contrast
to POSIX lock semantic.  That's fixed now and other than that glitch,
it worked.

However...

> I'll attach another script which implements the other suggested scheme
> with even more disturbing output:
> 
> 17:31:09 tmp$ ./fl-test.sh
> CYGWIN_NT-5.1 padrklemme1 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
> -rw-r--r-- 1 RKlemme Domain Users 0 Mar 12 17:31 lock
> timeout 10
> started 1 with PID 3160
> 1 1 Thu Mar 12 17:31:31 WEST 2009
> started 2 with PID 1848
> 2 1 Thu Mar 12 17:31:32 WEST 2009
> 1 2 Thu Mar 12 17:31:32 WEST 2009
> waiting...
> 2 2 Thu Mar 12 17:31:33 WEST 2009
> 1 3 Thu Mar 12 17:31:33 WEST 2009
> 2 3 Thu Mar 12 17:31:34 WEST 2009
> 1 4 Thu Mar 12 17:31:34 WEST 2009
> 2 4 Thu Mar 12 17:31:35 WEST 2009
> 1 5 Thu Mar 12 17:31:35 WEST 2009
> 2 5 Thu Mar 12 17:31:36 WEST 2009
> done
> 17:31:37 tmp$
> 
> Zero locking at all!

Cygwin won't be able to support the scenario from your second testcase
for the time being.  The reason is that in this scenario

  (
    flock -s 200
    ...
  ) 200> lockfile

the lock will end when the flock process exits.  The lock can only
persist as long as the process which created the lock, or any of the
child applications which inherited the file descriptor, still runs.  We
can't maintain a global file descriptor table with lock information like
the OS or what a master process could do if Cygwin would be designed so.

I know that's bad news, it certainly is for me since I thought I had
implemented flock with full BSD semantics, but we just can't do that
for now.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list