public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Date: Fri, 17 Apr 2015 12:10:00 -0000	[thread overview]
Message-ID: <20150417121052.GY3657@calimero.vinschen.de> (raw)
In-Reply-To: <20150417202746.351d90441d2d41fb316c07a9@nifty.ne.jp>

[-- Attachment #1: Type: text/plain, Size: 3179 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-04-17 12:10 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-28 12:40 Takashi Yano
2015-02-28 13:16 ` Denis Excoffier
2015-02-28 17:56 ` Corinna Vinschen
2015-03-02 11:45   ` Takashi Yano
2015-03-02 14:44     ` Corinna Vinschen
2015-03-02 14:50       ` Corinna Vinschen
2015-03-04 11:36       ` Takashi Yano
2015-03-04 12:43         ` Corinna Vinschen
2015-03-04 18:22           ` Corinna Vinschen
2015-03-04 20:25             ` Corinna Vinschen
2015-03-05 12:12             ` Takashi Yano
2015-03-05 13:31               ` Corinna Vinschen
2015-04-03  4:07                 ` Takashi Yano
2015-04-03  4:19                   ` Takashi Yano
2015-04-03 11:32                   ` Corinna Vinschen
2015-04-04  6:55                     ` Takashi Yano
2015-04-04  8:43                       ` Corinna Vinschen
2015-04-05 11:54                         ` Takashi Yano
2015-04-07  9:11                           ` Corinna Vinschen
2015-04-13 10:31                             ` Takashi Yano
2015-04-14  7:35                               ` Corinna Vinschen
2015-04-16  0:26                                 ` Takashi Yano
2015-04-16  9:05                                   ` Corinna Vinschen
2015-04-16  9:10                                     ` Corinna Vinschen
2015-04-17 11:27                                     ` Takashi Yano
2015-04-17 12:10                                       ` Corinna Vinschen [this message]
2015-04-17 12:25                                         ` Corinna Vinschen
2015-04-20 11:40                                         ` Takashi Yano
2015-04-20 15:12                                           ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150417121052.GY3657@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).