home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / wizards / 3751 < prev    next >
Encoding:
Text File  |  1992-08-31  |  3.6 KB  |  79 lines
  1. Newsgroups: comp.unix.wizards
  2. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!agate!usenet.ins.cwru.edu!cleveland.Freenet.Edu!am815
  3. From: am815@cleveland.Freenet.Edu (Joel Peter Anderson)
  4. Subject: Re: STREAMS M_ERROR Message problem
  5. Message-ID: <1992Aug31.144154.21347@usenet.ins.cwru.edu>
  6. Sender: news@usenet.ins.cwru.edu
  7. Nntp-Posting-Host: slc5.ins.cwru.edu
  8. Reply-To: am815@cleveland.Freenet.Edu (Joel Peter Anderson)
  9. Organization: Case Western Reserve University, Cleveland, OH (USA)
  10. References: <Btou5D.6DH@flatlin.ka.sub.org> <1992Aug26.130739.19300@usenet.ins.cwru.edu>
  11. Date: Mon, 31 Aug 92 14:41:54 GMT
  12. Lines:       66
  13.  
  14.  
  15. In a previous article, bad@flatlin.ka.sub.org (Christoph Badura) says:
  16.  
  17. >In <1992Aug26.130739.19300@usenet.ins.cwru.edu> am815@cleveland.Freenet.Edu (Joel Peter Anderson) writes:
  18. >>The result is the next read or write returns with a -1 and errno is
  19. >>set to 256 - status_code.  The PROBLEM is that the only way to
  20. >>clear the error condition is to close the device.  Typically, the
  21. >>error does not warrent a close.
  22. >
  23. >The *ONLY* way to clear the error condition caused by a M_ERROR
  24. >message is to close the stream. It's documented that way.
  25. >-- 
  26.  
  27. Well, yes, I found that document in the Vr3 Unix doco, however, this is 
  28. what I found in our manuals for Vr4:
  29.  
  30.  
  31. From the UHC supplied Unix Sys Vr4 documentation: [Streams manual,
  32. Appendix B, page 13; copyright 1990]
  33.  
  34. "Sent upstream by modules or drivers to report some downstream error
  35. condition.  When the message reaches the Stream head, the Stream is
  36. marked so that all subsequent system calls issued to the Stream,
  37. excluding close(2) and poll(2), will fail with errno set to the first
  38. data byte of the messge.  POLLERR is set if the Stream is being
  39. polled [see poll(2)].  All processes sleeping on a system call to the
  40. Stream are awakened.  An M_FLUSH message with FLUSHRW is sent downstream.
  41.  
  42. -------
  43. ok - that part sounds like what we see, M_ERROR sets an error on your
  44. Stream - close it to get rid of it.  But read on::
  45. -------
  46.  
  47.  
  48. The Stream head maintains two error fields, one for the read-side and
  49. one for the write-side.  The one byte format M_ERROR message sets
  50. both of these fields to the error specified by the first byte in the
  51. message. 
  52.  
  53. The second style of the M_ERROR message is two bytes long.  The first
  54. byte is the read error and second byte is the write error.  This
  55. allows modules to set a different error on the read-side and
  56. write-side. If one of the bytes is set to NOERROR, the the field for
  57. the corresponding side of the stream is unchanged.  This allows a
  58. module  to just [sic] an error on one side of the Stream.  For
  59. example,  if the Stream head was not in an error state and a module
  60. sent an M_ERROR message upstream with the first byte set to EPROTO
  61. and the second byte set to NOERROR, all subsequent read-like system
  62. calls (for example read, getmsg) will fail with EPROTO, but all
  63. write-like system calls (for example, write, putmsg)  will still
  64. succeed.  If a byte is set to 0, the error state is cleared for the
  65. corresponding side of theStream.  The values NOERROR and 0 are not
  66. valid for the one-byte form of the M_ERROR message."
  67.  
  68. ------
  69.  
  70. This is what we cannot get to work on our system.  I would be happy to
  71. be told we are wrong, that this was changed and the doco is outdated,
  72. or whatever... we just wanna know why the documentation says
  73. this is the case....
  74. -- 
  75. -------------------------------------------------------------------------
  76.   joela@apertus.mn.org           |Freenet: am815@cleveland.freenet.edu
  77.     Joel Peter Anderson          |PNET: jpa@pnet51.orbit.mn.org
  78.     Apertus Technologies         |GEnie:J.ANDERSON71
  79.