From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18614 invoked by alias); 21 Oct 2012 04:38:19 -0000 Received: (qmail 18413 invoked by uid 22791); 21 Oct 2012 04:38:17 -0000 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 Received: from mail-oa0-f43.google.com (HELO mail-oa0-f43.google.com) (209.85.219.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 21 Oct 2012 04:38:12 +0000 Received: by mail-oa0-f43.google.com with SMTP id k1so1681333oag.2 for ; Sat, 20 Oct 2012 21:38:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.177.72 with SMTP id co8mr4080744obc.53.1350794291859; Sat, 20 Oct 2012 21:38:11 -0700 (PDT) Received: by 10.76.114.233 with HTTP; Sat, 20 Oct 2012 21:38:11 -0700 (PDT) In-Reply-To: <20121019150037.GA17402@ednor.casa.cgf.cx> References: <5061B263.4090704@cs.utoronto.ca> <20121013153831.GA839@ednor.casa.cgf.cx> <20121019121729.GW25877@calimero.vinschen.de> <20121019150037.GA17402@ednor.casa.cgf.cx> Date: Sun, 21 Oct 2012 04:38:00 -0000 Message-ID: Subject: Re: mintty: Ctrl-Q does not work? From: Andy Koppe To: cygwin@cygwin.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-10/txt/msg00313.txt.bz2 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