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
