From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3eb59ec606364b7b,start X-Google-Attributes: gid103376,public From: George Rice Subject: Rational VADS 6.2.3a & Solaris signals Date: 1996/11/01 Message-ID: <327A4107.344A@lmtas.lmco.com>#1/1 X-Deja-AN: 193733156 cc: corcoran@mmc1001 content-type: text/plain; charset=us-ascii organization: Another Netscape News Server User mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m) Date: 1996-11-01T00:00:00+00:00 List-Id: I'm having a problem with UNIX signals. I have a set of processes running on a SPARCstation under Solaris 2.4. The programs are written in Ada using the Rational VADS 6.2.3a runtime environment. I am simulating a hardware environment and need to simulate bus interrupts between the processes. I have written Ada bindings to the sigsend system service and each process has a signal handler attached to the sigusr1 unix signal. To simulate the hardware interrupt, I use the Ada binding to send the sigusr1 signal to the other processes. In general, this system works but has the following problems: 1) I randomly see a Pending Kernel Service Queue Overflow error from the Rational runtime. It is my understanding that this is due to too many system service calls being queued while processing a signal. However, all the signal handler does is use the vads_exec library service to set a semaphore which another task is waiting on. The handler then goes back to waiting for the next signal. Our design is such that another signal will not be sent until all processes have indicated that the current signal has been serviced. I have increased the size of the pending kernel service queue via the Pending_Count parameter in the user configuration file but this did not help. 2) I also randomly see a missed signal. The signal sender blocks until all processes have serviced the interrupt. Occasionally our system hangs with the sender waiting on one process which has not received the signal. The sigsend to that process did not return an error yet the signal was apparently not received. By manually sending the sigusr1 signal to the process from an xterm, I can jumpstart the system and execution continues. 3) Also, the overhead associated with using signals seems to be excessive, about 1 ms per signal. Previously we were using the Verdix 2.1.1 runtime and the signal overhead was worse by about a factor of 10. It improved to where it is now when we went to the Rational 6.2.3a runtime. I don't know if this can by improved further or not. Has anyone out there had similar experiences? I welcome all comments and suggestions. Sean.A.Corcoran@lmtas.lmco.com -- (posted for Sean by:) George F. Rice 817-763-4216 (voice) 817-762-1444 (fax) George.F.Rice@lmtas.lmco.com http://webmmc.lmtas.lmco.com/~rice Technology Insertion MZ 5965, PO Box 748 Lockheed Martin Tactical Aircraft Systems Fort Worth, Tx 76101-0748