Message-Id:	<5.0.1.4.0.20001120202529.0345d780@pop5.banet.net>
X-Sender:	usbanet DOT farley3 AT pop5 DOT banet DOT net
X-Mailer:	QUALCOMM Windows Eudora Version 5.0.1
Date:	Mon, 20 Nov 2000 20:46:05 -0500
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
From:	"Peter J. Farley III" <pjfarley AT banet DOT net>
Subject:	Re: Q's re: F_GETLK and DOS/Win interfaces
Cc:	djgpp-workers AT delorie DOT com
In-Reply-To:	<Pine.SUN.3.91.1001120084338.24708F@is>
References:	<5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001119153421 DOT 02591e50 AT pop5 DOT banet DOT net>
Mime-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

At 08:43 AM 11/20/00 +0200, Eli Zaretskii wrote:
 >On Sun, 19 Nov 2000, Peter J. Farley III wrote:
 >
 >>In further researching the F_GETLK fcntl function, I see that Mark
 >>E.'s comment in his fcntl source that the int21/5C interface does 
not
 >>return information on what lock prevented this request is true, at
 >>least according to the Ralf Brown list.
 >
 >Please tell why do you need this.  Is it for filling the `flock'
 >structure in response to the F_GETLK request?

Yes.

 >If so, then I think the only way to supply the info would be to store
 >the information from F_SETLK (and flock/lockf, when we have them)
 >internally.  Do you see any problems with this approach in the 
context
 >of intended usage of these functions within Perl?

For perl modules that use the fcntl functions directly, yes.  I don't 
personally know of any, but I would imagine that the various perl 
database modules would be prime candidates.

AFAIK, core perl only uses flock functionality, and doesn't need 
F_GETLK.

But my idea here was not to duplicate existing system functionality 
needlessly, *if* there was a reasonable way to use that functionality 
to achieve the desired ends.  I don't really see the good in trying to 
track what the system is already doing.

And truthfully, if there are some perl modules that use record-locking 
that expect to get that information back when they can't get a lock, 
we'll just have to document what we do and don't support.

 >> I assume that the W9x and NT/2K replacement for SHARE.EXE, the
 >> IFSManager, has equivalent functions and data structures.
 >
 >The Windows replacement for SHARE.EXE is VSHARE, not IFSMgr.
 >
 >As for the internat data structures, there should be equivalent data
 >structures, but I won't bet on them being similar.
 >
 >> Q1:	Is there any doc (outside of a developer non-disclosure 
agreement
 >> with M$) on the API to the IFSManager locking functions?
 >
 >You could try searching RBIL for VSHARE.

Thanks, that would be one way to go.

 >> Q2:	If someone already knows about this API, is it worth our time
 >> trying to investigate it?
 >
 >I don't think so.  Locking support seems pretty much of marginal
 >importance in DJGPP (we've managed without it until now, didn't we?),
 >so I'd say maintaining the locking records inside the current program
 >is enough.  If we need to share this infor between different programs
 >running on Windows, we could devise some disk-based solution.

I was only trying to use data that someone else is already building and 
using, rather than re-inventing a solution.

In any case, I will get the error return from F_GETLK working right 
first.  If there is no way to implement the "blocking" lock data, then 
there isn't, and that will just have to be documented.

---------------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org OR
                      pjfarley AT banet DOT net)

- Raw text -