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

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

Hi Takashi,

On Mar  4 13:19, Corinna Vinschen wrote:
> On Mar  4 20:34, Takashi Yano wrote:
> > On Mon, 2 Mar 2015 15:44:26 +0100
> > Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> > > > To check buffer space before WriteFile() is one idea,
> > > > but it is not smart, I suppose...
> > > 
> > > I think that's not it.  [....blah...]
> > [...]
> > As a result of the test, it has become clear that this
> > modification conceals the problem. This means the problem
> > is closely related to occupancy of buffer.
> > 
> > Now, I suppose the cause has been clarified. So we have
> > to work out a solution. How can we resolve this problem?
> 
> I'm not sure.  I still have to look deeper into that.  Locally
> I treid to woraround this problem by calling WriteFile overlapped
> without waiting for the result, but even that doesn't work.

Ok, the good news is, I have a potential workaround for this problem.
The bad news is, it might be just a bad hack.

The problem is apparently that the slave fills up the to_master buffer.
If the master doesn't constantly and fastly read the slave output, the
slave will hang a lot in the WriteFile call and the pipe buffer is most
of the time full.  When the master itself calls doecho, it has a rather
high probability that the slave is in a WriteFile call.  The master will
hang in acquire_output_mutex while the slave hangs in WriteFile.  Worse,
even when removing the acquire/release_output_mutex bracket, there's an
just as high probablity that the master will hang in the WriteFile call.

If the master process is not handling reading and writing from the pipe
in different threads, but just using a single-threaded select loop, the
fate of both processes is sealed.

The obvious culprit here is that the master side echos into the same
pipe write side the slave is writing to.  It occured to me that the
problem should disappear if we decouple echo output from slave output.
So the idea was that doecho should write into its own echo pipe and
fhandler_pty_master::process_slave_output as well as select's peek_pipe
both check for data in the echo pipe.

The result is the patch I attached to this mail.  I'm not sure it's the
most feasible way to solve this problem, but it works pretty nicely for
me, including pasting big chunks (I tried a clipboard with about 70K
of data) while yes(1) is running.

As a side effect, we can get rid of the acquire/release_output_mutex
bracketing which should speed up output slightly (but reading on the
master side is slightly slower now...)


Please have a look.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: x.diff
Description: Text document

Attachment: pgpOEI93ZMO4V.pgp
Description: PGP signature