Date: Tue, 24 Aug 1999 12:52:10 +0930 From: Greg Lehey <grog@lemis.com> To: Christopher Masto <chris@netmonger.net> Cc: Chuck Robey <chuckr@picnic.mat.net>, Garance A Drosihn <drosih@rpi.edu>, "Daniel C. Sobral" <dcs@newsguy.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Matthew Dillon <dillon@apollo.backplane.com>, FreeBSD Hackers <hackers@FreeBSD.ORG>, FreeBSD Committers <cvs-committers@FreeBSD.ORG>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Subject: Re: Mandatory locking? Message-ID: <19990824125210.A83273@freebie.lemis.com> In-Reply-To: <19990823231130.A16133@netmonger.net>; from Christopher Masto on Mon, Aug 23, 1999 at 11:11:30PM -0400 References: <19990823223645.A14001@netmonger.net> <Pine.BSF.4.10.9908232256550.49952-100000@picnic.mat.net> <19990823231130.A16133@netmonger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990824125210.A83273>