From owner-svn-src-all@FreeBSD.ORG Sat Feb 11 18:51:44 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 387D7106566B; Sat, 11 Feb 2012 18:51:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id C20F58FC12; Sat, 11 Feb 2012 18:51:42 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1BIpX4K018501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Feb 2012 05:51:34 +1100 Date: Sun, 12 Feb 2012 05:51:33 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Martin Cracauer In-Reply-To: <20120211163807.GA25525@cons.org> Message-ID: <20120212040658.D4220@besplex.bde.org> References: <201202102216.q1AMGI0m098192@svn.freebsd.org> <20120211194854.J2214@besplex.bde.org> <20120211163807.GA25525@cons.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, Martin Cracauer , svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans Subject: Re: svn commit: r231449 - head/usr.bin/tee X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 18:51:44 -0000 On Sat, 11 Feb 2012, Martin Cracauer wrote: > I (kinda) knew I shouldn't have tried to do this real quick before > leaving for a trip. I reverted the change and I'll fix the concerns > including the commit message when I'm back in a week. Now I also want > to know what exactly is going on in bash there, the difference between > the explicit named pipe and bash'es construct is unexplained. > > Bruce, do you have a rule of thumb concerning reacting to EAGAIN with > select/poll or with a busy loop, or with one try instantly and then > going with select? I think using select() directly is best, except possibly if there is only 1 more byte to write. A pure busy loop with write() is too likely to write tinygrams, and one write() try before select() is too likely to either return EAGAIN, or succeed and write a tinygram, leading to further tinygrams. Devices should have output watermarks and not return from select() when there is only space to write a tinygram. BTW, one of the many bugs in the tty driver in -current is that it no longer does watermark processing for select() and poll(), so it reads and writes tinygrams even when polled using select() and poll() (and there is no better way). I use the following quick fix: % Index: ttydisc.h % =================================================================== % RCS file: /home/ncvs/src/sys/sys/ttydisc.h,v % retrieving revision 1.7 % diff -u -2 -r1.7 ttydisc.h % --- ttydisc.h 23 Aug 2009 08:04:40 -0000 1.7 % +++ ttydisc.h 25 Sep 2010 14:37:54 -0000 % @@ -70,8 +70,13 @@ % ttydisc_read_poll(struct tty *tp) % { % + size_t navail; % % tty_lock_assert(tp, MA_OWNED); % % - return ttyinq_bytescanonicalized(&tp->t_inq); % + navail = ttyinq_bytescanonicalized(&tp->t_inq); % + if ((tp->t_termios.c_lflag & ICANON) == 0 && % + navail < tp->t_termios.c_cc[VMIN] && tp->t_termios.c_cc[VTIME] == 0) % + navail = 0; % + return (navail); % } % % @@ -79,8 +84,10 @@ % ttydisc_write_poll(struct tty *tp) % { % + size_t nleft; % % tty_lock_assert(tp, MA_OWNED); % % - return ttyoutq_bytesleft(&tp->t_outq); % + nleft = ttyoutq_bytesleft(&tp->t_outq); % + return (nleft >= tp->t_outlow ? nleft : 0); % } % The watermarks that affect applications should be under control of the application like they are for sockets. There is only limited control of the read watermark for ttys, by enabling MIN and setting it as high as possible (the maximum is normally UCHAR_MAX which is normally 255), and this is not standardized, but it works in Linux and used to work in FreeBSD. The watermarks that affect drivers should be under control of drivers like they used to be. Bruce