home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / vms / 17780 < prev    next >
Encoding:
Internet Message Format  |  1992-11-10  |  2.8 KB
  1. Path: sparky!uunet!usc!cs.utexas.edu!sdd.hp.com!saimiri.primate.wisc.edu!usenet.coe.montana.edu!rpi!news.ans.net!cmcl2!rlgsc.com!gezelter
  2. From: gezelter@rlgsc.com
  3. Newsgroups: comp.os.vms
  4. Subject: Re: sys$hiber/sys$wake problems?
  5. Message-ID: <1992Nov11.003646.249@rlgsc.com>
  6. Date: 11 Nov 92 00:36:46 EST
  7. References: <BxIAFn.2p6@unx.sas.com> <1992Nov10.180054.23127@fripp.ri.cadre.com> <BxIrqM.2pF@unx.sas.com>
  8. Organization: Robert Gezelter Software Consultant, Flushing, NY
  9. Lines: 48
  10.  
  11. In article <BxIrqM.2pF@unx.sas.com>, sasjzs@falcon.unx.sas.com (Joseph Slater) writes:
  12. > 
  13. > In article <1992Nov10.180054.23127@fripp.ri.cadre.com>,
  14. >  rj@cadre.com (Rob deFriesse) writes:
  15. > |>
  16. > |>    If one or more wakeup requests are issued for the process while it is not
  17. > |>    hibernating, the next hibernate call returns immediately;  that is, the
  18. > |>    process does not hibernate.  ...
  19. > |>
  20. > |>This is, in fact, the correct behavior for a semaphore.  If it doesn't work
  21. > |>this way, your process could block indefinately.
  22. > |>
  23. > Hi Rob,
  24. >    And all others that responded via e-mail. You are correct, 
  25. > however we aren't the ones calling sys$wake. After leaving
  26. > sys$hiber the next-to-last time, the bit pcb$v_wakepen bit is
  27. > clear. The next time we start to enter sys$hiber it is set and
  28. > we don't call sys$wake anywhere in between. (This is what 
  29. > upsets us as we hope to set up things before calling sys$wake, 
  30. > and when we don't we exit from hiber in an unknown state). I
  31. > suspect (thanks Matt) the PPL$ runtime library as this scheme 
  32. > has worked successfully for many years and PPL is the only new 
  33. > variable in the scheme. My next task is to try to trap calls 
  34. > to sys$wake from the main and sharable images. Any ideas on 
  35. > doing this? I may have a hard time convicing our system manager 
  36. > to let me patch the system service vectors. Read that as slim to none. 
  37. > 
  38. > Joe Slater
  39. > sasjzs@vms.sas.com
  40. > Mine opinion is just that.
  41. -- 
  42. Joe,
  43.  
  44. Another option. Have a flag variable which you set from your WAKE 
  45. routine indicating that there is work to be done by the mainline 
  46. code. Then, when you get returned from the HIBER, if the flag 
  47. variable is NOT set, loop back to the HIBER. I first encountered 
  48. almost this exact problem in RSX, where a task could be 
  49. spuriously unstopped. 
  50.  
  51. - Bob
  52. +--------------------------------------------------------------------------+
  53. | Robert "Bob" Gezelter                       E-Mail:  gezelter@rlgsc.com  |
  54. | Robert Gezelter Software Consultant         Voice:   +1 718 463 1079     |
  55. | 35-20 167th Street, Suite 215               Fax:       (on Request)      |
  56. | Flushing, New York  11358-1731                                           |
  57. | United States of America                                                 |
  58. +--------------------------------------------------------------------------+
  59.