From owner-cvs-sys Thu Oct 26 00:40:02 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA18858 for cvs-sys-outgoing; Thu, 26 Oct 1995 00:40:02 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA18842 ; Thu, 26 Oct 1995 00:39:53 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA12694; Thu, 26 Oct 1995 17:33:46 +1000 Date: Thu, 26 Oct 1995 17:33:46 +1000 From: Bruce Evans Message-Id: <199510260733.RAA12694@godzilla.zeta.org.au> To: bde@zeta.org.au, davidg@Root.COM Subject: Re: cvs commit: src/sys/kern tty_pty.c Cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk >> I've been testing the changes here. These seem to fix the data loss >>problems, but a cntrl-C still causes everything to wedge until I kill the >>'od' in another window: > I forgot to mention that the old code did this, too, so this isn't a new >problem. >-DG >>root 179 112 196 508 ptcout S p0 11:54PM 0:01.71 od -v /dev/zero >>root 180 112 184 68 ttywai SE+ p0 11:54PM 0:00.54 cat /dev/ttyp8 [This is for od -v /dev/zero >/dev/ptyp8 & cat /dev/ttyp8 I didn't try to fix this. There may be no correct fix. It wouldn't be correct to abort any current i/o and return EOF/EIO for all future i/o on the master pty. Returning EOF for read() would be equivalent to not waiting in ptsclose() and returning EIO for write() would break output intended for other processes. There is interesting behaviour if another process reads from the slave: cat /dev/ttyp8 The od resumes output and the new cat reads it, but this has no effect on the wedged cat. The wedged cat is in last-close() while another process has the device open! Bad things might happen when the last-close() completes. It is probably a bug to allow opens of devices being last-close()d. Bruce