> The thing about well-intentioned but incorrect locking code is that > it will appear to work fine, until it trips over the one code path > where it forgets to lock some file that it should have locked. And > even then, the code will "work" just fine, until multiple processes > are accessing that file at the same time. > > I think it is appropriate for an operating system to provide an option > such that *it* (the system) will enforce the locking, and not have to > trust that all code-paths in all programs will do the right thing > WRT advisory locking.
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? -- Christopher Masto Senior Network Monkey NetMonger Communications ch...@netmonger.net i...@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
