home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / wizards / 3612 < prev    next >
Encoding:
Text File  |  1992-08-14  |  1.3 KB  |  40 lines
  1. Newsgroups: comp.unix.wizards
  2. Path: sparky!uunet!krfiny!jeffj
  3. From: jeffj@krfiny.uucp (J. Jonas)
  4. Subject: Re: flock(2) emulation?
  5. Message-ID: <1992Aug14.171020.20534@krfiny.uucp>
  6. Summary: you can roll your own
  7. Organization: Jeff's house of computer pieces
  8. References: <1992Aug7.173126.25686@htsa.aha.nl> <BsrzAp.7KD@ef2007.efhd.ford.com> <19480@fritz.filenet.com>
  9. Date: Fri, 14 Aug 1992 17:10:20 GMT
  10. Lines: 28
  11.  
  12. If I recall the history correctly:
  13. first was lockf(3) - a library that provided advisory record locking.
  14. Then it was rolled into the OS as flock(2), and lockf(3) became
  15. simply calls to flock.  This enabled manditory record locking
  16. (write(2) returns EAGAIN or blocks if it would overwrite a locked
  17. region of the file).
  18.  
  19. As mentioned in this newsgroup, the library probably kept a file
  20. containing
  21. - the file being locked (by major number/minor number/inode)
  22. - the region locked and the PID
  23. that way, all processes can access the global file and
  24. inspect each other's locks.
  25.  
  26. You might even place the table in shared memory.
  27.  
  28. The problem with advisory record locking is that a 'rude'
  29. program that doesn't respect the locking can destroy the file.
  30. Manditory record locking (having a file with the "get GID bit" set)
  31. enforces the lock by blocking writes on locked portions.
  32.  
  33. - Jeffrey Jonas
  34. jeffj@synsys.uucp
  35. -- 
  36. -- 
  37. Jeffrey Jonas
  38.  
  39. jeffj@synsys.uucp
  40.