Mail Archives: djgpp-workers/2000/11/30/03:16:50
On Wed, 29 Nov 2000, Peter J. Farley III wrote:
> >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".
To me, this means that there are no shared locks, as far as DOS is
concerned. Do you agree, or are you saying something different?
> 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.
Will it be good enough for those applications if we treat F_RDLCK as
if it were F_WRLCK?
Btw, Windows 9X will disallow some of the file accesses (when the file
is open) if another program has it already open. Perhaps that's what
Mark meant with ``read locks on per file basis''?
> 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.
I don't understand why do we need to confirm that the whole file is
being locked, for these cases.
> If later on, someone else wants to add logic to detect a plain-DOS,
> non-SHARE.EXE environment
The detection part is easy: Int 2Fh with AX=1000h will tell you if
SHARE is installed (and DTRT on Windows as well, AFAIK).
- Raw text -