X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-5.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_CG
X-Spam-Check-By:	sourceware.org
MIME-Version:	1.0
In-Reply-To:	<20121019150037.GA17402@ednor.casa.cgf.cx>
References:	<op DOT wk6rn9deofd6j1 AT nebbiolo> <5061B263 DOT 4090704 AT cs DOT utoronto DOT ca> <CAHWeT-Z-fRp_TzR4uf_8mAB3_usfBHGD-zLwej16Fxj3fG2o3w AT mail DOT gmail DOT com> <20121013153831 DOT GA839 AT ednor DOT casa DOT cgf DOT cx> <CAHWeT-bQ9BqPsVU0r4h5YB68bA7-rksh2sXtbgk3q_xkAObJ=w AT mail DOT gmail DOT com> <20121019121729 DOT GW25877 AT calimero DOT vinschen DOT de> <20121019150037 DOT GA17402 AT ednor DOT casa DOT cgf DOT cx>
Date:	Sun, 21 Oct 2012 05:38:11 +0100
Message-ID:	<CAHWeT-ZH5K76hp4=n72SGwRHmW_=pfWZFYadxrsgWBxUQedY9Q@mail.gmail.com>
Subject:	Re: mintty: Ctrl-Q does not work?
From:	Andy Koppe <andy DOT koppe AT gmail DOT com>
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

On 19 October 2012 16:00, Christopher Faylor wrote:
> On Fri, Oct 19, 2012 at 02:17:29PM +0200, Corinna Vinschen wrote:
>>On Oct 19 12:26, Andy Koppe wrote:
>>> On 13 October 2012 16:38, Christopher Faylor wrote:
>>> > On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote:
>>> >>The issue isn't specific to any of mintty, cat or Ctrl+S; for example,
>>> >>I've managed to reproduce it with xterm, hexdump, and just hitting
>>> >>Enter. Any other key that sends a keycode will do too. Ctrl+Q isn't
>>> >>needed for the freeze to happen. In xterm I've even managed it with
>>> >>find, by hitting Enter repeatedly.
>>> >>
>>> >>If you then look at the situation in ps, you'll see something like this:
>>> >>
>>> >>O    3396       1    3396       1472  ?       1004 05:11:07 /usr/bin/xterm
>>> >>O    3528    4460    3528        528  pty3    1004 05:25:01 /usr/bin/cat
>>> >>
>>> >>The interesting bit there is the two 'O's in the first column, which
>>> >>means both processes are waiting to output. I think what's happening
>>> >>is that both of them are trying to write to their side of the
>>> >>underlying pty device, but that those writes are blocking until data
>>> >>is read from the other side of the pty. Result: deadlock. If the cat
>>> >>is killed (possibly with -9, because of its nine lives), the terminal
>>> >>happily continues on its way.
>>> >>
>>> >>So why doesn't this happen more often? Not sure. The speed difference
>>> >>between the client process output and the terminal seems to play a
>>> >>role here. I can only guess that the issue occurs if a buffer in the
>>> >>pty's slave->master pipe overflows and something is written to the
>>> >>master->slave pipe at the same time (which is unbuffered?).
>>> >>
>>> >>I don't understand the pty implementation enough to verify any of
>>> >>that, so cgf would need to comment further. Note besides: I couldn't
>>> >>make this deadlock happen on Ubuntu.
>>> >
>>> > This should work in the latest snapshot.  I added a polling kludge for
>>> > 1.7.17 while I mull over the best way to handle this.
>>>
>>> Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat
>>> no longer freezes the terminal and that Ctrl+Q
>>>
>>> However, I still see the deadlock described above when hitting any
>>> other key that sends something, e.g. just Enter.
>>
>>Too bad.  Are you sure?  I tried really hard to get a deadlock and could
>>not reproduce it anymore under W7.  My Enter key is still on paracetamol.
>
> I can't duplicate it either.

Sorry I didn't get round to have another look at this before the 1.7.17 release.

I found that it's the CYGWIN=pipe_byte option that makes the
difference. In 1.7.16, the deadlock occurs with and without that
option. It 1.7.17, it only occurs with pipe_byte enabled.

Andy

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -