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
