On Monday, 23 August 1999 at 23:34:34 -0400, Christopher Masto wrote:
> On Tue, Aug 24, 1999 at 12:52:10PM +0930, Greg Lehey wrote:
>> 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
>
> How about a little timing difference?
>
> User 1 User 2
>
> open file
> read file
> open file
> lock file (blocks?)
> close file
> lock returns open file (blocks)
> diddle file
> unlock file
> scribble over User 1's changes
That's OK. In my scenario, user 2 can't know about what user 1 is
doing. Typically there'll be multiple accesses. Since you mentioned
mail, let's look at it, since that's where things really *do* use
(advisory) locking. When I save my mail folder, I need to ensure that
sendmail doesn't choose that moment to deliver a new message;
otherwise it might disappear completely. Mailers and sendmail do have
an agreement of some kind. But what if I want to merge the contents
of another mail folder:
cat oldmail >>/var/mail/grog
That works, but it's playing with fire: if sendmail is delivering a
message at the same time, it won't see me, and my cat doesn't get a
lock beforehand, so both an incoming message and part of my mail
folder could end up getting written to the same location. With
mandatory locking, it would work, transparently.
> What I'm getting at is that if User 2 has to do something special
> anyway, it might as well be using advisory locking.
What I'm getting at is that User 2 doesn't have to do anything
different.
>>> 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.
>
> That's not what I meant. It hasn't been on FreeBSD, so FreeBSD is not
> designed to deal with it.
Obviously.
> I mentioned a couple of examples.. if I lock a bunch of files in my
> web space, does apache get a bunch of children stuck forever?
Only as long as you keep them locked. And yes, you shouldn't go
locking files longer than you need them.
> Who knows what might get tripped up?
Nobody. Do you know where your next SIGSEGV is coming from?
Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message