Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-unix!hplabs!cae780!tektronix!reed!omen!caf
From: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Newsgroups: comp.unix.questions,comp.unix.xenix,comp.lang.c
Subject: Re: XENIX <-> ULTRIX interrupts & traps
Message-ID: <417@omen.UUCP>
Date: Thu, 13-Nov-86 14:36:49 EST
Article-I.D.: omen.417
Posted: Thu Nov 13 14:36:49 1986
Date-Received: Thu, 13-Nov-86 22:04:07 EST
References: <43@samira.UUCP>
Reply-To: caf@.UUCP (PUT YOUR NAME HERE)
Distribution: net
Organization: Omen Technology, Portland
Lines: 20
Xref: mnetor comp.unix.questions:40 comp.unix.xenix:6 comp.lang.c:35

In article <43@samira.UUCP> mike@samira.UUCP (Mike Deutsch) writes:
:Under XENIX, when the program returns from the interrupt handler, the
:program doesn't still expect to be reading at the read where the interrupt
:trap was received.  Under ULTRIX, it does.
 ....
:2)  I'd prefer the program to function as it does under XENIX.  How can
:I get it to not continue with the read when there was an interrupt during
:the read?

A longjmp from within the interrupt handler should do the trick.  When 4.2 BSD
changed the way signals affected read calls, thus breaking rb/sb, I changed
the interrupt handler from the previous no-op (just let the read fail) to a
longjmp.  Just make sure the longjmp always has a valid place to long jump to!

Chuck Forsberg WA7KGX Author of Pro-YAM communications Tools for PCDOS and Unix
...!tektronix!reed!omen!caf  Omen Technology Inc "The High Reliability Software"
  Voice: 503-621-3406  17505-V Northwest Sauvie Island Road Portland OR 97231
TeleGodzilla BBS: 621-3746 2400/1200  CIS:70007,2304  Genie:CAF  Source:TCE022
  omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
  omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourly