Re: flock still buggy

[Eric Blake <ebb9 at byu dot net>]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:

> 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.

Oh, right.  So the problem boils down to: if we created the file table entry 
(via open, pipe, socket...) and obtained the lock, then we can properly 
propogate lock details to all duplicate handles (dup) and child processes 
(fork), even across changes in Windows pid (exec).

But if we inherited the file table entry and obtain the lock, we need some way 
to inform all other clients of that file table entry (parent process and any 
other sibling processes) that their fd now owns a lock.

Does the shared memory of cygheap allow us to push information back to parent 
processes?  In the child, can we distinguish between inherited fds vs. fds that 
created a file table entry?

Just thinking aloud: Maybe, for every parent process that calls fork(), we 
create an Event object for each file table entry created in that parent in the 
same flock-dev-ino namespace, and set up a thread that waits indefinitely on 
that Event.  Meanwhile, in children, if flock() is ever called on an inherited 
fd, then part of creating a lock on the fd is also waking up the Event, so that 
the parent can read the shared memory and learn that a lock was obtained.  That 
way, the parent will have a handle prior to the child exiting, so that the 
child no longer breaks the lock.

On the other hand, that may get expensive, since it means creating a lot of 
Events, even though most fork()s don't end up doing flock on something from the 
parent.

But maybe we don't need a new event - we already have a way to signal arbitrary 
processes - maybe the trick is that if flock() ever obtains the lock on an 
inherited file table entry, then it uses the signal mechanism to wake up the 
parent with a special signal number that tells the parent to check if it needs 
to grab a handle to reflect the lock in the child.

Hmm, if the parent has forked multiple times, then it could be more than one 
process that needs to be signaled that a child grabbed a flock.  That could get 
expensive, trying to track through all existing cygwin processes to make all 
such processes grab a new handle because one of their distant relatives called 
flock on the file table entry (particularly if someone tries to use flock on 
the stdout tty).

It seems like for every file table entry we create, we want a piece of shared 
memory listing the processes interested in that file table entry (the list 
grows on fork, and is updated on exec), so that when any one of the owners of a 
handle to that entry creates an flock, it wakes up all related processes to 
also open a handle to the flock.

But no pressure to get this done by 1.7.1.

-- 
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