home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / sun / hardware / 3865 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  4.7 KB
  1. Path: sparky!uunet!auspex-gw!guy
  2. From: guy@Auspex.COM (Guy Harris)
  3. Newsgroups: comp.sys.sun.hardware
  4. Subject: Re: Additional RS232 ports
  5. Message-ID: <14050@auspex-gw.auspex.com>
  6. Date: 14 Aug 92 02:48:37 GMT
  7. References: <1992Aug12.141935.18721@aristo.tau.ac.il> <l8lqs1INNd7b@appserv.Eng.Sun.COM>
  8. Sender: news@auspex-gw.auspex.com
  9. Organization: Auspex Systems, Santa Clara
  10. Lines: 93
  11. Nntp-Posting-Host: bootme.auspex.com
  12.  
  13. >The root cause of the problem,
  14. >however, has to do with AT&T's STREAMS code not honoring a non-blocking
  15. >close() call nor following the STREAMS close() semantics of timing out after
  16. >a certain period of time from when the user application did a close() to the
  17. >serial port and there was still data to be sent to the device.
  18.  
  19. Eh?
  20.  
  21. AT&T's code *does* honor closes on non-blocking descriptors, and *does*
  22. time out after STRTIMOUT seconds, as of SVR3.1.
  23.  
  24. The SunOS 4.x code is derived from the SVR3.1 code, and it does the
  25. same.
  26.  
  27. *HOWEVER*:
  28.  
  29. That very behavior caused *bugs* to be filed against SunOS 4.0.  The
  30. problem is that if you have a printer (or other output device; I think
  31. one complaint was about a plotter) attached to a serial port, and that
  32. printer requires flow control, and the software that drives the printer
  33. writes a bunch of stuff to the printer and then closes the printer, then
  34. if the printer takes too long to print out the last stuff written to it,
  35. the stream gets dismantled while stuff is still queued up to get sent to
  36. the printer, and Bad Things Happen.
  37.  
  38. In particular, once "ldterm" is popped off the stream, you don't get
  39. ^S/^Q flow control any more, and you run the risk of overrunning the
  40. printer.
  41.  
  42. The workaround I suggested when those bugs started arriving was to have
  43. some other process hold the serial port open, so that the stream *isn't*
  44. dismantled when the close is done.
  45.  
  46. I think that kept the problem from occurring, but it's kind of ugly, and
  47. I guess the tech support people may have gotten tired of explaining it
  48. over and over again, so the ^S/^Q flow control stuff was moved down to
  49. the driver, at least in one of the serial port patches.
  50.  
  51. In 4.1, the flow control stuff was moved out of the driver, and "ldterm"
  52. was changed so that, in its close routine, it sent an "ioctl" streams
  53. message downstream, doing a TCSBRK "ioctl" with a non-zero argument.  A
  54. TCSBRK with a non-zero argument blocks waiting for all output to drain. 
  55. This means that the "ldterm" close routine will block until output
  56. drains - no matter how long that takes.
  57.  
  58. Now, at least in the case of printers like that, the STREAMS close
  59. semantics are Very Bad, as indicated (anyone who disagrees with that
  60. will be sentenced to 100 years in purgatory answering calls from SunOS
  61. 4.0 customers whose printers don't work :-)).  (In fact, my first
  62. unpleasant encounter with AT&T-style tty close semantics was with System
  63. III, long before any System N release had STREAMS; the problem described
  64. above occurred, because the printer in question required ^S/^Q to be
  65. honored.)
  66.  
  67. Unfortunately, that means that if the port *never* drains, a close can
  68. hang forever.
  69.  
  70. In part, that can be fixed by making sure that if carrier drops, all
  71. queued-up data is flushed, *and* any TCSBRK "ioctl"s waiting for output
  72. to drain get an acknowledgement sent upstream, so that the close can
  73. continue.  A quick look at the "zs" driver indicates that this might not
  74. happen; the code that sends the M_HANGUP message upstream when carrier
  75. drops doesn't flush all queued-up data.  If so, that might be the cause
  76. of the problem.
  77.  
  78. That fix should mean that if some ^S'ed output was pending when carrier
  79. dropped, and a close was blocked waiting for the output to drain, the
  80. close would unblock.  It would have to be applied to all serial port
  81. drivers.
  82.  
  83. It still doesn't handle the case where the line has soft carrier, and
  84. somebody ^S's output and then turns the terminal off, say.  If somebody
  85. then kills off that person's session, the close will, I think, hang
  86. until somebody turns the terminal back on again and does a ^Q.
  87.  
  88. To handle *that* problem, the "wait for output to drain" must be made
  89. optional.  This could be done by:
  90.  
  91.     1) having some "ioctl" to specify whether a close should do that
  92.        or not.
  93.  
  94.        If wait-for-output-to-drain were made the default, "getty" or
  95.        "ttymon" or whatever would presumably turn it off.
  96.  
  97.        If it were *not* the default, any code doing printing would
  98.        probably want to turn it *on* if the printer required flow
  99.        control, unless the mode is "sticky" (i.e., unlike most UNIX
  100.        tty modes, persists even after the last close), in which case
  101.        you could have one of the "/etc/rc" files set that mode on
  102.        the ports with printers of that sort on them.
  103.  
  104.     2) having any code doing printing explicitly do the TCSBRK
  105.        "ioctl" before closing the port.
  106.