This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

flock still buggy


I finally figured out why autoconf is still failing its flock-related tests, 
and why perl was reliably failing even though my simple attempts in C were 
always passing.  It turns out that if you do:

open
flock(LOCK_EX)
if (!fork)
  execlp("sleep","sleep","10",NULL);
sleep(10);

then ProcessExplorer shows that the Event in the global namespace of flock-dev-
ino\20-2-* exists in both parent and child, and with a notification level of 
false, blocking any outside influence until both the parent and forkee exit.  
But if you do:

open
fcntl (fd, F_SETFD, FD_CLOEXEC | fcntl (fd, F_GETFD))
flock(LOCK_EX)
if (!fork)
  execlp("sleep","sleep","10",NULL);
sleep(10);

then only the parent holds a handle to the Event, but with a notification level 
of true, allowing any outside party to do whatever they want.

I'm still trying to figure out why the close-on-exec cleanup appears to be 
spuriously triggering the flock Event to unlock.  But my understanding is that 
F_FLOCK locks should survive over exec, so the close-on-exec cleanup should 
only trigger lock release on F_POSIX locks.

-- 
Eric Blake



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]