Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Wed, 14 Aug 2002 21:21:24 +0200
From: Pavel Tsekov <ptsekov AT gmx DOT net>
Reply-To: Pavel Tsekov <ptsekov AT gmx DOT net>
X-Priority: 3 (Normal)
Message-ID: <7216699292.20020814212124@gmx.net>
To: cygwin-developers AT cygwin DOT com
Subject: Advisory file lockig for Cygwin
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello, there! :)

I would like to implement advisory file locking for Cygwin. I've
searched the developers list about this but found only one complaint
about this missing feature and no other comments on the topic (maybe I
havent searched hard enough).

I've thought a bit on the problem and want to share my thoughts so
people can comment and offer their own opinions on that topic.

Here you go...

1. Support an array of structures (in shared memory) containing information for the
current active/pending locking requests for each file, for which a lock
request was issued. The file inode number would be used as a key.

2. Each of this structures (1) will contain a linked list of structures
describing all active locks on that file.

3. The pending locks (blocking lock requests) would be stored in an
alternative linked list containing the same type of structures as in
2 along with an event object on which blocking lock requests will wait.
On removal of a lock from the active lock list the next item in the
pending locks list would be signaled so the waiting process can fulfill
the request.

4. Access to all this will be synchornized through a single muto
object.

I understand this is pretty rough description but I would welcome any
questions. I would also appreciate any opinions on how to implement this
in a better way.

Now a question I currently have and want an expert opinion on it...
The shared memory used to store all the data necessary for the locking.
I browsed the source of path.cc looking at mount_info class but I
dont't see any requests for allocating/deallocating memory from the heap.
I know that I will need to alloc more data as more locking requests are
processed, but I don't know exactly how to do that. If allocate memory via
normal functions I would get memory from the currently executing process's
heap, so I won't be able to access it in other processes which hold locks...
Now I know this may sound really stupid... still I will appreacite help on that
topic. Maybe the solution is to create a list of data blocks allocated
from the shared memory and expand it on demand and store inside the
data structures.

Thanks!

Pavel Tsekov