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

[Corinna Vinschen]

On Apr 20 20:40, Takashi Yano wrote:
> Hi Corinna,
> 
> On Fri, 17 Apr 2015 14:10:52 +0200
> Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
> > > @@ -868,6 +980,9 @@ fhandler_pty_slave::tcgetattr (struct termios *t)
> > >  int
> > >  fhandler_pty_slave::tcsetattr (int, const struct termios *t)
> > >  {
> > > +  DWORD n;
> > > +  while (::bytes_available (n, from_slave) && n)
> > > +    cygwait (10);
> > >    acquire_output_mutex (INFINITE);
> > >    get_ttyp ()->ti = *t;
> > >    release_output_mutex ();
> > 
> > Shouldn't this loop be skipped in TCSANOW mode?
> 
> In Linux (Debian), TCSANOW and TCSADRAIN seem to behave in the same way
> for PTY. In other words, both of them do not affect the data already
> written, even if master does not read them yet. So I think that skipping
> the loop for TCSANOW is not necessary.
> 
> > IIUC, what you'd really like to know is something else.  It's not about
> > having n > 0 bytes in the pipe, but on calling tcsetattr, you'd like to
> > know how much bytes are in the pipe at this very moment, and then you'd
> > overwrite the termios info as soon as these n bytes are written.  That
> > sounds pretty different to me.
> 
> You are right. If the slave is only one, both are same. However, they are
> quite different when more than one slave exists.
> 
> On Fri, 17 Apr 2015 14:25:42 +0200
> Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
> > Maybe your idea to introduce a second pipe wasn't that bad after all...
> > 
> > So, instead of using it for Cygwin slave I/O (which makes me cringe a
> > bit), it could be used as a command channel to the master.  Since only
> > Cygwin executables would understand this concept anyway, it's ok that
> > native applications don't know about it.  This pipe could then be used
> > to transmit tcsetattr info to the master, and the master could apply the
> > change when it sees fit.  Maybe we even realize it could be used for
> > something else in future.  Ctrl-S/Ctrl-Q processing might be nice, say.
> > 
> > What do you think?
> 
> For implementation of this idea, the application of c_oflag should be
> queued and postponed until master-side reads the data written before
> tcsetattr(). However, application of other members in struct termios
> should not be postponed because they affect PTY input.
> 
> Furthermore, tcgetattr() should return the latest values set by
> tcsetattr(), even if the application of c_oflag is still postponed.
> 
> After all, this implementation does not sound also very simple. This
> complicated situation is caused because OPOST processing is placed in
> master-read-side and it has a delay.
> 
> By any chance, my first implementation may be simpler.

Ok.  Let's go with that.  Can you please rename handle2/master2 to
handle_cyg/master_cyg and resend the patch to the cygwin-patches
mailing list?


Thanks,
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/20150420/4b92c86f/attachment.sig>