Mail Archives: cygwin/2009/07/22/12:39:35
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
- Raw text -