home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / vms / 21707 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  3.1 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: re: Re: Recursion in Vax Fortran
  5. Message-ID: <9301201734.AA18357@uu3.psi.com>
  6. Date: 20 Jan 93 16:34:07 GMT
  7. Sender: usenet@ucbvax.BERKELEY.EDU
  8. Organization: The Internet
  9. Lines: 58
  10.  
  11.  
  12.     The issue of recursion in VMS Fortran has worried me for a while.  In
  13.     doing some real-time programming I need to monitor a process every so
  14.     often and am using the sys$setimr() routine to do it.  The ast calls
  15.     itself until some external event occurs and I execute a sys$cantim().
  16.     The problem is that the ast routine looks like it is calling itself
  17.     within the call to sys$setimr(), as seen below.  My simplistic
  18.     solution has been to create a dummy routine (also below).  This
  19.     solution has worked fine for several years, but now I wonder whether
  20.     there is a safer solution?
  21.  
  22.     ! update routine for FOLLOW command
  23.             subroutine follow_update_ast( ident)
  24.             common /timer/ delta_time(2)
  25.             integer delta_time, ident, sys$setimr
  26.             external dum_follow_ast
  27.     ! executable code
  28.             call update_screen
  29.             istat = sys$setimr(%val( 0), delta_time,
  30.             1       dum_follow_ast, ident) ! motors still moving
  31.             if (.not. istat) call lib$signal( %val( istat))
  32.             return
  33.             end
  34.     !**************************************************************
  35.             subroutine dum_follow_ast( ident)
  36.             integer*4 ident
  37.             call follow_update_ast( ident)
  38.             return
  39.             end
  40.  
  41. Your code is NOT an example of recursion.  There will only be one active
  42. instance of follow_update_ast at a time; the call to SYS$SETIMR merely
  43. requests that the same routine be called again later.  Even if the timer
  44. goes off immediately, the resulting AST can't be delivered because you are
  45. already IN an AST routine, so delivery is blocked; it won't be unblocked until
  46. follow_update_ast returns, dismissing the AST.  Of course, at that point it's
  47. OK to call it again - there will still be only one active instance at a time.
  48.  
  49. If follow_update_ast were a function rather than a subroutine, you'd have a
  50. syntactic problem:  Within the text of the function, the name of that function
  51. acts as a variable (to receive the return value), so cannot be used to refer
  52. to the function itself.  With a subroutine, which doesn't return a value,
  53. in principle there should be no problem; but a couple of quick experiments
  54. reveal that FORTRAN will not let you use the name of a subroutine in a call
  55. within the subroutine itself.  One obvious trick - declaring follow_update_ast
  56. as external within its own code - also fails.
  57.  
  58. The code you've got is correct and will work, since there is no real
  59. recursion.  It costs you one additional procedure call every time the timer
  60. AST goes off, which is probably not worth worrying about.  If it were to
  61. become a problem, you could have code outside of follow_update_ast stash its
  62. address in a common block.  follow_update_ast would see it as, say, variable
  63. MYSELF, and you'd pass %VAL(MYSELF) to SYS$SETIMR.
  64.  
  65. If there's some more direct way to do this, I'm sure some experience VAX
  66. FORTRAN hacker out there will let us know.
  67.                             -- Jerry
  68.  
  69.