From owner-freebsd-current@FreeBSD.ORG Sun Nov 9 11:15:38 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F16E16A4CE for ; Sun, 9 Nov 2003 11:15:38 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A686443FD7 for ; Sun, 9 Nov 2003 11:15:37 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id hA9JFTeF064374; Sun, 9 Nov 2003 11:15:34 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200311091915.hA9JFTeF064374@gw.catspoiler.org> Date: Sun, 9 Nov 2003 11:15:29 -0800 (PST) From: Don Lewis To: bde@zeta.org.au In-Reply-To: <20031109192046.L2537@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: current@FreeBSD.org Subject: Re: serial console oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2003 19:15:38 -0000 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?