Mail Archives: djgpp-workers/2000/11/29/23:41:10
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)
- Raw text -