home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.vms
- Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!pa.dec.com!nntpd2.cxo.dec.com!adserv.enet.dec.com!winalski
- From: winalski@adserv.enet.dec.com (Paul S. Winalski)
- Subject: Re: sys$hiber/sys$wake problems?
- Message-ID: <1992Nov11.031322.4195@nntpd2.cxo.dec.com>
- Lines: 36
- Sender: usenet@nntpd2.cxo.dec.com (USENET News System)
- Reply-To: winalski@adserv.enet.dec.com (Paul S. Winalski)
- Organization: Digital Equipment Corporation, Nashua NH
- References: <BxIAFn.2p6@unx.sas.com> <1992Nov10.180054.23127@fripp.ri.cadre.com> <BxIrqM.2pF@unx.sas.com>
- Date: Wed, 11 Nov 1992 03:13:22 GMT
-
-
- In article <BxIrqM.2pF@unx.sas.com>,
- sasjzs@falcon.unx.sas.com (Joseph Slater) writes:
-
- [discussion of problem with $HIBER wait being terminated unexpectedly, PPL$
- routines suspected]
-
- |>My next task is to try to trap calls
- |>to sys$wake from the main and sharable images. Any ideas on
- |>doing this? I may have a hard time convicing our system manager
- |>to let me patch the system service vectors. Read that as slim to none.
-
- Don't bother. Your conjecture that PPL$ library routines are doing the $WAKE
- is most likely correct. PPL$ is within its rights to use the $HIBER/$WAKE
- mechanism.
-
- If your application cannot tolerate spurious $WAKEs, then it is not properly
- coded. A piece of code that is event-driven and uses $HIBER should be coded
- as follows:
-
- while (1)
- {
- while (there are things to do)
- do the next work item;
-
- SYS$HIBER();
- }
-
- A structure such as this insures that, if the process awakens from the $HIBER
- when there are no work items, it will go back into hibernation again. The
- semaphore nature of $WAKE (that a $HIBER returns immediately if a $WAKE was
- issued while not in HIB state) insures that if an AST adds a work item to the
- work queue and does a $WAKE while the main program has left the inner while,
- but has not yet issued the $HIBER, the program will not stall.
-
- --PSW
-