Cygwin hangs up if several keys are typed during outputting a lot of texts.

[Corinna Vinschen]

Hi Takashi,

On Mar  2 20:45, Takashi Yano wrote:
> On Sat, 28 Feb 2015 15:02:51 +0100
> Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
> > Hmm, I can reproduce this even with stty -echo.  The tty code is not
> 
> Some shells seem to re-enable echo when it goes back into prompt.
> Please put both 'stty' and 'yes' in one command line, separating
> them with semi-colon.

Uh, ok, I didn't realize that.

> > exactly my domain, so I'm not sure at the moment where to look.  I guess
> > the locking strategy in the tty code is not robust enough.  Did you have
> > a look into the cygwin sources in the meantime, by any chance?
> 
> To tell the truth, I have looked into the source code.
> I guess the mechanism of blocking is as follows.
> 
> 1) Buffer of named pipe gets full-filled by a lot of data written
>   by slave side.
> 2) WriteFile() in fhandler_pty_master::doecho(), which is called
>   from master side by key input, is blocked because the buffer
>   is full.
> 3) If a handling to read from the pipe is in the same thread as
>   key input, the thread falls into deadlock.
> 
> To check buffer space before WriteFile() is one idea,
> but it is not smart, I suppose...

I think that's not it.  For testing I added code to convert the
WriteFile calls in fhandler_pty_slave::write, fhandler_pty_master::doecho
and fhandler_pty_slave::write to overlapped I/O and made sure to wait
for the result after the output mutex has been released.

This change has no effect at all.  Looks like this needs some more
digging.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20150302/0ff057cc/attachment.sig>