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.

On Apr 17 14:10, Corinna Vinschen wrote:
> On Apr 17 20:27, Takashi Yano 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?
> > 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?

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?

I'm sorry if I let you jump through hoops here, but I'm not really
sure about the best solution either :}


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

Attachment: pgpDw9FyD1J5d.pgp
Description: PGP signature

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