Date: Sat, 7 Jun 1997 14:31:47 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, straka@inficad.com Cc: current@freebsd.org Subject: Re: sio driver performance Message-ID: <199706070431.OAA28487@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>I have noticed that the communications work great until I interrupt the >process on the box which is tranmitting the data. At that point, the box >which was receiving suddenly elevates to 100% CPU usage (mostly system) as >if in a polling loop. When I attempt to reestablish the process which is Hangup on the tranmitter breaks the connection. There is no way (*) to get the same connection back - reads on the open fd will return -1/EIO forever. (Reads should return 0, but there is a minor bug that prevents this in some cases. POSIX allows either EOF (0) or -1/EIO.) You need to clear HUPCL on the transmitter or set CLOCAL on the receiver to avoid seeing the hangup. Using CLOCAL is often required to avoid unwanted POSIX connection semantics. Then you have to monitor the carrier status directly by polling it if you care about it. (*) actually there is a nonstandard way involving toggling CLOCAL. Don't use it. >sending the data, I get "tty-level buffer overflows" on the receiving box, >the read never unblocks and the CPU utilization stays at 100%. I have to >kill the receiving process and restart it to reestablish communication. This may be a driver bug. The new input apparently gets buffered but nothing reads it. It can't be read via the old connection, so perhaps it should be discarded. Well behaved receivers close the port when they see EOF or -1/EIO, and input to closed ports is ignored, so the problem is usually invisible. >Also when the receive process is started, before the transmit process is >started on the other box, the read seems to periodically return -1. >Shouldn't the read indefinitely block if c_cc[VMIN]=1 and c_cc[VTIME]=0? It should block before the first connection and return either EOF or -1/EIO when the connection is broken. Stale broken connections may interfere with new connections in some cases. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706070431.OAA28487>