| Title: | "ASK THE WIZARDS" |
| Moderator: | QUARK::LIONEL |
| Created: | Mon Oct 30 1995 |
| Last Modified: | Mon May 12 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1857 |
| Total number of notes: | 3728 |
Return-Path: "VMS001::WWW"@vms001.das-x.dec.com Received: by vmsmkt.zko.dec.com (UCX V4.1-12, OpenVMS V6.2 VAX); Mon, 24 Mar 1997 15:10:31 -0500 Received: from vms001 by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id PAA05545; Mon, 24 Mar 1997 15:02:44 -0500 (EST) Date: Mon, 24 Mar 1997 15:05:14 -0500 Message-Id: <[email protected]> From: "VMS001::WWW"@vms001.das-x.dec.com (24-Mar-1997 1505) To: [email protected], [email protected], [email protected] Subject: Ask the Wizard: '[email protected]' X-VMS-To: [email protected] Remote Host: (null) Browser Type: Mozilla/3.0 (WinNT; I) Remote Info: <null> Name: Monique Semp Email Address: [email protected] CPU Architecture: VAX Version: v 6.2 Questions: Dear Wizard, I am porting a C/DecForms Application from earlier versions: DECC: from 3.2-046 to 5.3 O/S: from ? to 6.2 DecForms: from 1.3 to 2.1B All code ran correctly under old development system. I am having a problem with my new code. Application code 'Process A' handles the interface with the DecForms. Communication is done by escape sequences (that is, the C code just uses forms$enable, forms$disable calls, but no forms$receive calls). For certain DecForms selections, Process A sends a msg to C-application Process B, sets a timeout ast routine, and then is supposed to sys$hiber. It is intended that Process A hibernate until the timeout expires (in which case the timeout ast routine will issue the sys$wake), or until Process A receives a msg back from Process B (in which case the mailbox read ast routine will issue the sys$wake). The problem I'm having is that the sys$hiber() call doesn't seem to be working. fprintf() calls that include the time show 0 time elapsed between the sys$hiber() call and the next statement in the code. It's as if I don't even have the sys$hiber() call in the code. The status back from the sys$hiber() call is fine. I've checked to be sure that there was no previous sys$wake call to process A while it wasn't in the hiber state. I do have a timer ast routine that updates a clock display on the DecForms by the forms$send() mechanism. It appears to be correctly using the FORMS$K_ASTADR argument in the item list. Do you have any suggestions? Does the fact that the new DecForms is "thread-safe" (multi-threaded?) have any influence? Thanks much!
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1695.1 | probably a spurious wakeup... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Tue Mar 25 1997 14:27 | 20 |
sys$hiber receives extensive testing and use throughout the operating system and various layered products. While a bug is certainly still possible, it is relatively unlikely. My assumption is that there is failure in the sys$hiber call (though your test seems to indicate not), or there is a pending wakeup, or that there is a sys$wake call executing in code you are unaware of, possibly in a layered product or even executing in the context of the debugger. Per standard programming techniques and documentation, a sys$hiber call should be able to correctly contend with a spurious sys$wake call. As options, include a "I really meant to wake up" flag (possibly via an interlocked bitflag) in the application, and check that flag and drop back into sys$hiber if it was not set. Alternatively, one could issue a sys$wake, sys$hiber, sys$hiber sequence. This will clear any pending wake-up requests. | |||||