Date: Sun, 9 Nov 2003 11:15:29 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: bde@zeta.org.au Cc: current@FreeBSD.org Subject: Re: serial console oddity Message-ID: <200311091915.hA9JFTeF064374@gw.catspoiler.org> In-Reply-To: <20031109192046.L2537@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 Nov, Bruce Evans wrote:
> For a non-half-baked fix, do somethng like:
> - never block in ttymsg(), but always wait for output to drain using
> tcdrain() in a single child process. It's probably acceptable for
> this to not report errors to ttymsg()'s caller.
> - limit children better. I think we now fork children iff writev()
> returns EWOULDBLOCK and this happens mainly when the tty buffers
> fill up due to clocal being off and the external console not
> listening. Handling this right seems to require handing off the
> messages to a single child process that can buffer the messages
> in userland and can block writing and draining them. Blocked write()s
> and tcdrain()s are easy enough to handle in a specialized process by
> sending signals to abort them.
Another way of handling EWOULDBLOCK would be to add the descriptor to
syslogd's select loop instead of forking a child process. There is
still the issue of how to handle blocking trdrain()s or close()s,
perhaps a thread. Syslogd should not attempt to re-open the device if a
tcdrain() or close() was in progress.
BTW, it sounds like the pending output should not be discarded by the
close(), the termios(4) man page says:
Closing a Terminal Device File
The last process to close a terminal device file causes any output to be
sent to the device and any input to be discarded.
If output is discarded in the O_NONBLOCK case, it seems to be
undocumented. Should close() return ENOSPC in this case?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311091915.hA9JFTeF064374>