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

[Corinna Vinschen]

Hi Takashi,

On Apr 17 20:27, Takashi Yano wrote:
> Hi Corinna,
> 
> On Thu, 16 Apr 2015 11:05:33 +0200
> Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
> > Ok, but... this is a really big patch and it complicates the pty code
> > even more.  Is there really no other option as far as the TCSADRAIN
> > problem is concerned?
> > 
> > What strikes me as weird is that neither fhandler_pty_slave::tcsetattr
> > nor fhandler_pty_master::tcsetattr give a damn for the optional_actions
> > parameter.  They simply overwrite the tc settings.  So I'm wondering,
> > wouldn't it be possible to add code to the tcsetattr implementation
> > instead, so that TCSADRAIN/TCSAFLUSH are honored and than only have one
> > place for OPOST handling?
> 
> I also think the patch was a big deal. However, I did not have
> any other good idea.
> 
> Anyway, I have worked out another solution. Please find a patch
> attached.
> 
> What do you think of this one?

Looks better to me.   However:

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

> OPOST code has been now completely moved back to master side as
> with original implementation.
> 
> With this patch, tcsetattr() waits until master reads all data
> in pipe before new attributes are applied to preserve the order
> between write() and tcsetattr().
> 
> However, there is a potential risk in which tcsetattr() can be
> blocked if master stops reading pipe, even though I can not imagine
> such a likely situation.

Yeah, but it is a busy wait.  Hmm.  Also, on second thought, the above
loop checks for bytes_available every time and changes n.  So, if
another slave writes lots of data, wouldn't the slave calling tcsetattr
starve?

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.

It would be cool if the slave-side tcsetattr only transmits the
optional_actions and the new termios content to the master, and the
master keeps it stashed away together with the number of bytes in the
pipe right now.  Then in, say, process_slave_output, it checks if the
precondition is fulfilled and only then overwrites its termios
structure.

Off the top of my head I'm not sure how feasible this is.  One way to do
that *may* be to send the info in the normal write pipe to the master.
What we need then would be a method to identify such a tcsetattr packet
in the input stream.

Other ideas?


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/20150417/7b55dc44/attachment.sig>