home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / pascal / 7926 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  2.0 KB
  1. Path: sparky!uunet!paladin.american.edu!gatech!prism!gtd543a
  2. From: gtd543a@prism.gatech.EDU (death)
  3. Newsgroups: comp.lang.pascal
  4. Subject: Re: File locking question
  5. Message-ID: <79288@hydra.gatech.EDU>
  6. Date: 6 Jan 93 23:00:04 GMT
  7. References: <Hendrik.Klompmaker.34.726306175@beheer.zod.wau.nl>
  8. Organization: Purgatory
  9. Lines: 39
  10. X-Newsreader: Tin 1.1 PL5
  11.  
  12. Hendrik Klompmaker (Hendrik.Klompmaker@beheer.zod.wau.nl) wrote:
  13. : In article <1993Jan5.220346.24647@csx.cciw.ca> u055@csx.cciw.ca (James Sprenger) writes:
  14. : 
  15. : >
  16. : >>
  17. : >> So my guess  is that your program username should:
  18. : >>
  19. : >>  -be compiled with $I-  (no stop on runtime error)
  20. : >>
  21. : >>  -Repeat
  22. : >>     -try to open the file in mode $11 (Write and deny ALL)
  23. : >>  -Until (IoResult=0)  (* nobody else has locked it *)
  24. : >>
  25. : >
  26. : >
  27. : Indeed it does not work. I came up with the following working solution. I 
  28. : did not find a way to chech if a file was locked useing ioresult or doserror 
  29. : while reset(ing) or append(ing) a file. It does however get set if do the 
  30. : following
  31. : {$i-}
  32. : repeat
  33. :   setattr(logf,$20); {Archive bit set}
  34. : until doserror = 0;
  35.  
  36. All of these methods are -bad-, B-A-D bad.  In network management you
  37. meet up with something called deadlock.  It occurs when one program
  38. wants file X, and already has open file Y, and when a second program
  39. wants file Y, and already has open file X.  Neither will be satisfied
  40. until the other releases a file wanted by the other.  If you create
  41. an infinite "repeat until unlocked" loop you foolishly run the risk
  42. of deadlock, which both eats a lot of resources (repeated requests
  43. through the network) and locks further progress.  Always make a 
  44. timeout or some other default (like max number of retries) failsafe
  45. into whatever low level locking scheme you use.: 
  46. -- 
  47. =========================================================================
  48. WANTED:  Position for experienced Matrix runner.  Demanding and ambitious
  49. positions welcome.  Must have support for a FUCHI XNN1-11-22 cyberdeck.
  50. =========================================================================
  51.