Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!ucla-cs!zen!ucbvax!VENUS.YCC.YALE.EDU!leichter From: leichter@VENUS.YCC.YALE.EDU ("Jerry Leichter") Newsgroups: comp.os.vms Subject: re: CONTROL-C AST's and CONDITION HANDLERS Message-ID: <8709190825.AA29820@ucbvax.Berkeley.EDU> Date: Thu, 17-Sep-87 15:19:00 EDT Article-I.D.: ucbvax.8709190825.AA29820 Posted: Thu Sep 17 15:19:00 1987 Date-Received: Sun, 20-Sep-87 13:03:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Jerry Leichter" Organization: The ARPA Internet Lines: 39 I am having a problem with FORTRAN and asynchronous interrupt. I enable control-c trapping, and when a ctrl-C occurs, the AST-routine signals (by means of LIB$STOP or LIB$SIGNAL) the condition SS$_CONTROLC This condition is trapped by a condition-handler which looks if (LIB$MATCH_COND(SA(2),SS$_CONTROLC) .EQ. 1) and then does as $UNWIND(MA(3),), so there is a stack-unwind to the establisher of the conditionhandler. So far evrything works fine, save one thing. When a control-C occurs during an outstanding PRINT *,'kjgsafhsfhskahfsd' as i can make occur by pressing control-s so text is half written, and then control-c, I get no further text written to the terminal by next calls to PRINT *,'sdajykgsdqkjfdgfhj' No error occurs, and the program continues, but no output is generated to the terminal anymore. What's happening is that you are unwinding across a call to a FORTRAN I/O routine. The FORTRAN I/O routines are not able to deal with this; I'm not sure ANY of the language RTL's can deal with it gracefully. It's not just the I/O routines - unwinding asynchronously through a routine is giving it a rather massive kick in the shins. Recovering successfully may be difficult or just outright impossible. In any case, there are a lot of RTL routines that will not survive this process unscathed. The FORTRAN I/O routines will survive, but the particular channel being accessed at the time of the interrupt probably will not. As you've noted, you can no longer get to the terminal - since it was the terminal that the I/O system was working on at the time of the interruption. You may be able to recover by closing and re-opening the channel - if, as in this case, you can determine which one it is. (I'm not familiar enough with FORTRAN to know if there is a way to close and re-open the default channel that PRINT * writes to.) The general solution is for the CTRL/C AST routine to set a flag which is tested in the mainline code, and then simply dismiss the interrupt. That way, you have control over exactly where the interruption actually occurs - and you can make sure it happens within your code, which you can write to deal with such an event gracefully, and not within the RTL. -- Jerry ------