Date: Fri, 06 Jun 1997 23:02:10 -0500 From: Wm Brian McCane <root@bmccane.uit.net> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: straka@inficad.com (Richard Straka), bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: sio driver performance Message-ID: <199706070402.XAA26092@bmccane.uit.net> In-Reply-To: Your message of "Fri, 06 Jun 1997 16:26:30 %2B0930." <199706060656.QAA02486@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> Richard Straka stands accused of saying: > > > > 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. > > Read the manpage for the read() system call, and pay particular > attention to the return value for EOF. I suspect that when the sender > is killed it is lowering whatever control signal is driving DCD at the > receiving end. Without seeing the rest of your code, it's hard to be > sure if this is the case. > > > 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? > > Check errno on these occasions; I would guess that you are probably > seeing EINTR. > > > The "tty-level buffer overflows" only occurs after the transmit process is > > started, then halted, then restarted. This could be a real problem for my > > remote test equipment as the serial lines may be inadvertently > > disconnected and reconnected from time to time. > > I suspect that this is an artifact of the receiver having lost its brain. > > > Richard Straka > I think Mike is right on this one. I would suggest adding a select call to your program with a read and exception fd_set. If the bit gets set in the exception fd_set, close the port and reopen it. This way you will wait until DCD is high before continuing your reads. It also makes a nice spring-board for when someone asks you to monitor more ports at once. brian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706070402.XAA26092>