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 From: "Peter J. Farley III" Subject: Re: Q's re: F_GETLK and DOS/Win interfaces Cc: djgpp-workers AT delorie DOT com In-Reply-To: References: <5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001119153421 DOT 02591e50 AT pop5 DOT banet DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Precedence: bulk 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)