Hi Takashi, On Mar 2 20:45, Takashi Yano wrote: > On Sat, 28 Feb 2015 15:02:51 +0100 > Corinna Vinschen 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