From owner-freebsd-arch@FreeBSD.ORG Mon Apr 14 19:18:23 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3F141065672 for ; Mon, 14 Apr 2008 19:18:23 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 5A18C8FC37 for ; Mon, 14 Apr 2008 19:18:23 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 7C5601CD30; Mon, 14 Apr 2008 21:14:53 +0200 (CEST) Date: Mon, 14 Apr 2008 21:14:53 +0200 From: Ed Schouten To: Poul-Henning Kamp Message-ID: <20080414191453.GK5934@hoeg.nl> References: <20080414074710.GI5934@hoeg.nl> <5287.1208159704@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ht+/lPZLak6eP81R" Content-Disposition: inline In-Reply-To: <5287.1208159704@critter.freebsd.dk> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: arch@freebsd.org Subject: Re: f_offset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2008 19:18:23 -0000 --Ht+/lPZLak6eP81R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Poul-Henning, Sorry, I forgot to reply to your message this afternoon. * Poul-Henning Kamp wrote: > In message <20080414074710.GI5934@hoeg.nl>, Ed Schouten writes: >=20 > >I'm experiencing similar problems with implementing read() and write() > >inside my mpsafetty branch for TTY's. Just like the current TTY > >implementation, my implementation will do strange things when two > >threads call read() or write() at the same time. Data could end up mixed > >together. >=20 > The write side of this will break quite a lot of stuff, starting > with syslogd(8), write(1), wall(1) and similar, all which expect > to be able to spam terminals coherently. >=20 > The read side will probably mostly cause trouble for programs that > try to take input from /dev/tty, usually passwords. I'll explain what I've done with the TTY layer somewhat more in depth. I was a little brief in my last message. It is true that the read()-side of the TTY layer doesn't really offer much guarantees when multiple applications try to perform a read() on both the TTY device or the PTY controller device. I've tried to prevent as much copying as possible, so unlike the current code there isn't a buffer in between. A compromise I had to make was that read()'s on TTY's aren't serialized. I don't think this will cause a problem: - PTY controller devices aren't really intended to be read() by multiple threads at the same time. - It's not likely multiple read()'s on the TTY device will happen a lot. When a background process group tries to perform a read(), it will most likely receive a SIGTTIN (except when it ignores the signal, etc). - I am sure this will not cause any problems in canonical mode, because there is already a guarantee that the VEOL/VEOF character will always be processed by the thread that first detected it. It is not possible that the character is interpreted by multiple readers. Now about the write() case. I said write()'s were completely unprotected, but I was a little brief about this. Because it's too complex to implement an unbuffered mechanism that copies data from userspace directly into the buffer queue (makes locking hard, input could be processed to expand to a different amount of bytes, etc), write() calls will be buffered. There are only two cases where a write() may end up fragmented when multiple write() calls would happen at the same time: - The write() exceeds the write buffer size of 256 bytes (100 bytes with the current TTY layer). Maybe I should adjust this value, because 256 bytes may be a lot when allocated on the stack. - The write() call causes the calling thread to be blocked, because the TTY has reached its high watermark. All in all I think the way I've implemented the TTY layer should be quite safe. Its guarantees don't differ too much when compared to the existing implementation, in my opinion. --=20 Ed Schouten WWW: http://g-rave.nl/ --Ht+/lPZLak6eP81R Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkgDrS0ACgkQ52SDGA2eCwX8kACdHbYeBzOOtqEHDiJwRZ+NsLKz OssAniUX/VbObXglktgx1EHEVBeacJsM =+YxA -----END PGP SIGNATURE----- --Ht+/lPZLak6eP81R--