Date: Tue, 23 Oct 2012 19:40:28 -0700 From: Jeremy Chadwick <jdc@koitsu.org> To: Ed Schouten <ed@80386.nl> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-stable@freebsd.org, jhb@freebsd.org Subject: Re: pty/tty or signal strangeness, or grep/bsdgrep bug? Message-ID: <20121024024028.GA90747@icarus.home.lan> In-Reply-To: <CAJOYFBDhDMwgPyWRrzj021eqN=meS3q2FfTi9=5xpVPcXrNxYg@mail.gmail.com> References: <20121023142703.GA79098@icarus.home.lan> <20121023203928.GZ35915@deviant.kiev.zoral.com.ua> <CAJOYFBDhDMwgPyWRrzj021eqN=meS3q2FfTi9=5xpVPcXrNxYg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 23, 2012 at 10:42:47PM +0200, Ed Schouten wrote:
> Hi Kostik,
>
> 2012/10/23 Konstantin Belousov <kostikbel@gmail.com>:
> > This is reproducable with the cat(1) as well. The telling part is that
> > the backgrounded process stays on the "ttyin" cv. The code for e.g.
> > tty read currently is structured as follows:
> > check for background process reading from CTTY, send SIGTTYIN
> > loop {
> > sleep waiting for input
> > process input
> > }
> > The problem is that the SIGCONT does not remove the sleeping process from
> > the sleep queue, so the sleep is not interrupted with error. Instead, the
> > process is woken up later when input is available.
> >
> > Old tty code did the recheck for background state inside the loop after
> > the sleep.
>
> Exactly. Was just debugging this as well and came to the same
> conclusion. Will try to come up with a decent patch tomorrow evening.
>
> Thanks for reporting the issue!
No problem folks. Would you like me to file a PR for this so we can
track it/for historical purposes?
--
| Jeremy Chadwick jdc@koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121024024028.GA90747>