Bug in MacTCP solved!

[gat@robotics.jpl.nasa.gov (Erann Gat)]

I finally found the bug in the MacTCP utilities.  (Thanks to the person
from Chicago who gave me the vital clue - unfortunately, I erased yout
message so I don't know who you are.)  It seems that MacTCP bombs if
passed the same parameter block as one which is being used in a pending
asynchronous call.  This causes passive streams to fail because their
print method calls MacTCP to get the state of the stream.  The following
is a quick fix:

(defun  %tcp-control (pb code &optional ignore-error-p)
  (when (= code $tcppassiveopen)
    (setf (rref pb tcpioPB.open.commandtimeoutvalue) 0)
    (setq pb (copy-record pb)))
  (setf (rref pb tcpioPB.csCode) code
        (rref pb tcpioPB.ioCompletion) (%null-ptr))
  (let* ((err nil))
    (progn
        (loop
          (when (and (eql (setq err (#_control :async pb)) 0))
            (let* ((*interrupt-level* 0))
              (while (> (setq err (rref pb tcpioPB.ioResult)) 0))))
          (unless (or ignore-error-p (eql err 0))
          (%tcp-err-disp err))
        err)))

This fix is not quite right, since it leaves undisposed parameter blocks
floating around, but I don't feel like polishing it up just now.

(I have heard very little from other MCL people about this bug.  Am I really
the only one having this problem?)

Erann Gat