I#<881104-51482>: Mark eating bug in neti:buffered-stream-with-mark

[Christopher Maeda <maeda@MCC.COM>]

    Date: Sun, 8 Jan 89 08:36 PST
    From: trev@VERMITHRAX.SCH.Symbolics.COM

	Date: Fri, 4 Nov 88 11:56 CST
	From: Christopher Maeda <maeda@MCC.COM>

	This seems to fix the problem.

	neti::
	(defmethod (:listen buffered-stream-with-mark) ()
	  (send raw-stream :read-input-buffer "EOF in listen" t))

	Chris

    Thanks for the fix...I still haven't been
    able to verify the problem, but other TCP
    sites have reported stream-sync problems
    along these lines (this is a TCP method?).
    How often was this happening, and has it
    happened since you installed the patch?

    Belatedly,
    trev 

This was in TCP.  I don't know if it will happen in Chaos (though I
think it will).  The problem was that no one ever defined a proper
listen method for this flavor (nfile waits for marks using
stream-copy-until-eof) and it was getting the default method.  This
default method did something like the following:

(defmethod (:listen random-base-stream-flavor :default) ()
  (condition-case ()
       (send stream :setup-next-input-buffer ...)
     (error
       t)))

The problem was that the :setup-next-input-buffer method for
buffered-stream-with-mark was the one responsible for signalling
mark-seen conditions.  Thus, mark-seen conditions were getting caught
(and consumed) by the condition-case macro.

BTW The patch I sent is incorrect since it will signal errors in the
scheduler.  The patch we've been using around here is the following:

neti::
(defmethod (:listen buffered-stream-with-mark) ()
  (condition-case ()
       (send raw-stream :read-input-buffer "EOF" t)
     (error t)))

Everything worked fine after I installed this patch.  I can send you a
piece of code that might help you in verifying the problem.  I set up a
user and server end that just passed marks to each other.  When I had
the mark receiver wait for marks using listen, it never saw any.  When I
used stream-copy-until-eof, it saw every one.