Message-Id: <5.0.1.4.0.20001129230443.0259fec0@pop5.banet.net> X-Sender: usbanet DOT farley3 AT pop5 DOT banet DOT net X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Wed, 29 Nov 2000 23:41:48 -0500 To: Eli Zaretskii From: "Peter J. Farley III" Subject: Re: Locking fcntl() and flock() patches Cc: "Mark E." , djgpp-workers AT delorie DOT com In-Reply-To: References: <3A243B9A DOT 31778 DOT 2984396 AT localhost> 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 10:14 AM 11/29/00 +0200, Eli Zaretskii wrote: > >On Tue, 28 Nov 2000, Mark E. wrote: > >> Also, I believe I wrote the mysterious comment (from my original >> code): >> /* DOS/Windows only support read locks on a per-file basis, >> so any attempted use of a read lock is an error. */ >> >> based on some document, possibly the RBIL. Perhaps a better way to >> have put it would have been: >> /* DOS/Windows 9x do not support read locks, so any attempted use >> is an error. */ > >This is indeed what I glean from RBIL: read (i.e., shared) locks are >simply unsupported. I wonder how should we translate this into our >implementation. Perhaps simply let SHARE/VSHARE do its thing, and if >the fail, return with a failure? I just re-read RBIL on int21/5C, and I agree with Mark's comment now. RBIL says, "locked regions become entirely inaccessible to other processes". Without implementing our own table of shared read locks, there is no way we can implement a true read lock. Even treating a "whole file" read lock as a write lock might seem wrong, in light of that. My only concern here would be for applications (like perl) that use flock() to issue a LOCK_SH (i.e., F_RDLCK) type of lock, the idea being to prevent modification by a writer process so a file can be read without being changed unexpectedly. Because of this, I would argue that we do need to keep the exception to the DOS limitation that Mark originally coded, even if it takes a bit more work to confirm it is indeed a "whole file" lock. This will allow most of the functionality that applications need, albeit without the simultaneous access implied by a LOCK_SH request. Each requester will have to wait for the other(s) to unlock before access is granted, but that's better than failing the request, forcing coders (and particularly porters) to code their flock() logic differently. And for plain DOS, it will simply let the one running process run, thinking it has the LOCK_SH it requested, though it doesn't, of course, need it in that environment. Assuming that the evil SHARE.EXE is loaded, of course. If later on, someone else wants to add logic to detect a plain-DOS, non-SHARE.EXE environment, and automatically return success on all lock/unlock requests from fcntl() for that particular case, I wouldn't mind. That would let plain-DOS users run normally without loading SHARE.EXE, though it *would* have the distinct disadvantage of hiding program locking errors in newly-written code (e.g., locking the file or a region twice without an intervening unlock) until the program was run in a "real" locking environment. >> I can go along with the extra file handle checks, but I don't really >> think they're neccessary because the early _get_dev_info test does >> the job of filtering out bad handles. > >That's true, but I'm worried by possible changes of the code in the >future, including the case that someone will rip the internal >functions out of fcntl.c and make them public (like already happened >with mntent.c). OK, the file handle checks will be coded. --------------------------------------------------------- Peter J. Farley III (pjfarley AT dorsai DOT org OR pjfarley AT banet DOT net)