Date: Sun, 3 Aug 1997 13:58:23 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: henrich@crh.cl.msu.edu (Charles Henrich) Cc: msmith@atrad.adelaide.edu.au, tom@sdf.com, freebsd-hackers@FreeBSD.ORG Subject: Re: tty-level buffer overflows Message-ID: <199708032058.NAA02222@phaeton.artisoft.com> In-Reply-To: <19970803112147.21483@crh.cl.msu.edu> from "Charles Henrich" at Aug 3, 97 11:21:47 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Your application is busted; data is arriving faster than your app is reading > > it, and the kernel has run out of patience and started throwing the data > > away. > > Im afraid not, the application is a software Upload, with a singly byte ack > every 2k, if the serial port cant handle that, theres a problem. I would > presume that if the buffer is full, a write() should block. Input and output buffers are seperate. If they weren't, the original "cu" program, which forked using a reader and a writer as seperate processes to create the illusion of a full duplex connection, would have failed (nb: "cu" predates the select(2) and poll(2) calls). For async I/O, it would mean that a queued read request would need to complete before a queued write request could complete (nb: this was a bad problem with VMS QIO() services for full duplex protocols on serial ports, and is generally a problem for most "multidrop" serial port board drivers for commercial UNIX implementations; for example, the Altos 2000). So anyway, your input buffer is filling up. Please see my other posting for what you can do about it. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708032058.NAA02222>