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]

Re: flock still buggy


On Jul 22 16:18, Eric Blake wrote:
> 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?

We can inform the parent process via an internal mechanism, but, if the
child process is running under another, non-admin account, the child
has no right to signal the parent.

And then there are the potential sibling processes.

You got the problem quite well in your musings.

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

There is such a structure, it's the file table entry (aka FILE_OBJECT)
in the kernel.  Unfortunately we have no way to inject information into
this entry.  And then, every parent and sibling which still has a descriptor
open to the file needs to create the datastructures maintained in flock.cc.
That's what's usually done in the OS, at least on POSIX systems.  I really
thought utilizing the NT namespace to maintain the information wold be
the ultimate solution, but I didn't realize this problem with BSD locks
when I implemented this.  It looks again like a problem which can only
be correctly handled by using Cygserver to maintain the locks.

> But no pressure to get this done by 1.7.1.

Yeah.  I guess I will have to implement this in Cygserver at one point.
I just hate it that we will have to rely on running a service for such
basic stuff.


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


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