On Monday, 23 August 1999 at 23:11:30 -0400, Christopher Masto wrote:
> On Mon, Aug 23, 1999 at 10:59:10PM -0400, Chuck Robey wrote:
>>> Dunno about that.. if you're using advisory locking, you know to say
>>> "lock the file, then read the data, do your calculation, write it out,
>>> and unlock". This manditory locking sounds like an invitation for
>>> disaster. "I don't need to pay attention to the details because
>>> the kernel will take care of it for me."
>>>
>>> Actually, I don't really understand the paradigm. Two processes need
>>> to safely update a file, so one of them aquires a mandatory lock, and
>>> the other.. uh.. just blocks trying to open the file? How does it
>>> know it's not the first one?
>>
>> It means that if user A puts data in (and follows locking procedure
>> correctly) then he doesn't have to worry that user B might not be
>> following correct locking procedure, because user B is mandatorily
>> forced to follow the procedure. There isn't any added sloppiness, just
>> a guarantee that if one user locks a file, no other rogues can get into
>> it while the lock exists.
>
> Bleah.. I can't count the number of times I've seen idiotic code like:
>
> open file
> read data
> close file
> open file for write
> write data
> close file
>
> Mandatory locking of the type above doesn't force such a thing to
> work.
I don't see a consistency problem in the code above, it's just
inefficient.
> Now that I've read the rest of the thread, I see that the meaning may
> be that certain files are marked such that they can't be opened
> without locking.
No, I think you're confusing opening and locking. It's something like
this:
User 1 User 2
open file open file
lock file read file (blocks)
diddle file
unlock file
read completes
In fact, fcntl locking is range locking, not file locking, so as long
as the two users don't want to access the same part of the file.
> That seems extremely dangerous, given all the time that such a thing
> hasn't been around..
I've been using it for 22 years now.
> who knows how many scripts and programs will now be vulnerable to
> hanging forever..
Why? There is a danger, of course, that user 1 will lock the file and
not unlock it. That's a badly written program, so you stop it. End
of hang.
Greg
--
See complete headers for address, home page and phone numbers
finger g...@lemis.com for PGP public key
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
