home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / modula3 / 1039 < prev    next >
Encoding:
Text File  |  1992-11-19  |  3.6 KB  |  104 lines
  1. Newsgroups: comp.lang.modula3
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!decwrl!pa.dec.com!rdg.dec.com!jch
  3. From: jch@rdg.dec.com (John Haxby)
  4. Subject: Failing system calls and threads
  5. Message-ID: <1992Nov20.120734.23671@rdg.dec.com>
  6. Sender: news@rdg.dec.com (Mr News)
  7. Organization: Digital Equipment Corporation
  8. Date: Fri, 20 Nov 1992 12:07:34 GMT
  9. Lines: 93
  10.  
  11. [First, an apology, this is rather longer that I thought it
  12.  would be.]
  13.  
  14.  
  15. Hello,
  16.  
  17.     While I was writing `cat' (as one does) I tripped up over an
  18. interesting problem around system calls.  The problem revolves around
  19. accurately dealing with system call failures.  In C this is easy, one
  20. writes:
  21.  
  22.     if (write (fd, buf, sz) < 0)
  23.         if (errno == EINTR)
  24.             /* try again */
  25.         else
  26.             perror ("write")
  27.  
  28. (more-or-less).  The equivalent code in SRC Modula-3 (2.07) is somewhat
  29. similar, at least in spirit, and this is where the problems arise.
  30. Obviously, if some other thread gets to run between the call to write() and
  31. the examination of errno then the value of errno may no longer be valid or
  32. useful when you come to look at it.
  33.  
  34. The obvious way around this is to protect the code with some suitable
  35. mutex, eg
  36.  
  37.     LOCK Cerrno.mu DO
  38.         write (...)
  39.         IF Cerrno.errno ...
  40.     END
  41.  
  42. but this has at least three significant problems: the overhead in acquiring
  43. a lock around every system call is non-negligable (I assume); not all uses
  44. of errno are guaranteed to be protected (especially in uses within C
  45. libraries); only one outstanding system call is can be permitted (in an
  46. environement that uses kernel-supported threads).
  47.  
  48. I was thinking about all this while I was making the children's breakfast
  49. this morning: these problems do make using the present Modula-3
  50. implementation somewhat tricky for a good many of the (commercial)
  51. applications I had in mind.  However, whilst putting milk on the Rice
  52. Krispies, it occurred to me that there is a solution, at least for ULTRIX
  53. and probably BSD UNIX.
  54.  
  55. Before I suggest a solution, though, am I barking up the right tree?  Does
  56. what I say make sense or have I missed something in the implementation?
  57.  
  58.  
  59.  
  60. The solution comes from knowing that errno is introduced by the C library
  61. and not by the kernel: the kernel returns a result and an indication of
  62. whether that result is an error code or a returned value.  On a VAX, the
  63. indication is the carry flag, on a (DEC) mips machine, the indication
  64. is left in a register when the syscall instruction `returns'.  The
  65. implementation of the solution involves re-writing all of the system calls
  66. so that the are of the form (expressed in C)
  67.  
  68.     int err = sysfunc (&res, arg1, arg2, ...);
  69.  
  70. The &res is only written to the if the return result is non-zero; the
  71. return result is otherwise what would be written to errno.  The Modula-3
  72. implementation of, say, Unix.write would then look something like this
  73. (syntax notwithstanding :-):
  74.  
  75. PROCEDURE write (fd: INT; buf: REFANY; sz: INTEGER): INTEGER RAISES{syserr} = 
  76.   VAR
  77.     err: INTEGER;
  78.     res: INTEGER;
  79.   BEGIN
  80.     err := system.syscall (system.write, res, fd, buf, sz);
  81.     IF err # 0 THEN
  82.       RAISE syserr(err)
  83.     ELSE
  84.       RETURN res
  85.    END
  86. END write.
  87.  
  88. Does this make sense?  Will it avoid the problems I mentioned earlier?
  89. And, a question for the other implementations: can this form of solution be
  90. used? (specifically, are there any implementations out there where errno is
  91. explicitly known by the kernel?)
  92.  
  93.  
  94.  
  95.  
  96.  
  97. -- 
  98. John Haxby, Definitively Wrong.
  99. Digital                <jch@rdg.dec.com>
  100. Reading, England        <...!uknet!wessex!jch>
  101.  
  102. ----------------------------------------------------------------
  103. The opinions expressed herein are my own, not my employers.
  104.