Date: Sun, 12 Feb 2012 05:51:33 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Martin Cracauer <cracauer@cons.org> Cc: svn-src-head@freebsd.org, Martin Cracauer <cracauer@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r231449 - head/usr.bin/tee Message-ID: <20120212040658.D4220@besplex.bde.org> In-Reply-To: <20120211163807.GA25525@cons.org> References: <201202102216.q1AMGI0m098192@svn.freebsd.org> <20120211194854.J2214@besplex.bde.org> <20120211163807.GA25525@cons.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120212040658.D4220>