Mail Archives: cygwin/2009/07/22/11:42:37
On Jul 22 15:27, Eric Blake wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
>
> > > $ ./foo 4& sleep 2; ./foo 0
> > >
> > > Oops - process 14060 got the lock before 12692 and 21704 exited.
> >
> > This looks different with my patch:
> >
>
> Yep, so far, it looks like your patch follows the semantics I expect for every
> one of my tests (the lock remains until explicitly unlocked, or until all
> handles are closed, whether by explicit close, process exit, or close-on-
> exec). And the original autoconf question which raised this issue in the first
> place now passes.
>
> I'm not sure whether there are lurking bugs in fcntl/lockf locking, but I think
> we've finally nailed the last of the flock bugs.
Thanks, but no. There's at least this one problem left which I simply
don't know how to fix. The situation is thus:
fd = open()
fork ()
--> child
flock(fd, LOCK_SH);
exit ();
The problem is that the lock disappears when the child exits, even
though the parent has still an open descriptor to the file. This
problem disallows usage of the flock(1) utility like this:
(
flock -s 200
# ... commands executed under lock ...
) 200>/var/lock/mylockfile
I wish I knew how to implement this...
> Nothing. I guess I wasn't thinking straight on this case - a fork is
> not the same as exec, and I validated that even without your patch,
> flock(LOCK_UN) fails on closed fd, and close-on-exec does close the fd
> when I actually get to the exec.
>
> By the way, your posted patch missed out on fhandler.cc; I assume this
> is what you meant:
> [...]
Exactly. Thank you. I'll apply the patch in a minute.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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
- Raw text -