This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mintty: Ctrl-Q does not work?


On Sun, Oct 21, 2012 at 05:38:11AM +0100, Andy Koppe wrote:
>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.

Still can't duplicate it.  pipe_byte was designed to be used only with
anonymous pipes and not with ptys so it shouldn't have any effect on
pty handling.

cgf

--
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]