This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]