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

Corinna Vinschen corinna-cygwin@cygwin.com
Thu Apr 16 09:05:00 GMT 2015


Hi Takashi,

On Apr 16 09:26, Takashi Yano wrote:
> Hi Corinna,
> 
> On Tue, 14 Apr 2015 09:34:56 +0200
> Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
> > And the native client, not knowing what he's talking to, recognizes the
> > output stream as a normal named pipe, if it's looking for that info at
> > all.  Being native, it will use native Windows MSVCRT stdio calls.
> > Worse, as you can see in the behaviour of some native applications, the
> > MSVCRT isatty() call returns 0 for named pipes.
> > 
> > If we have a Cygwin client, we can do all kinds of stuff on the slave
> > side, but as soon as we have a native client, only the master side of
> > the pty has any chance to do the right thing.  That's why I wrote that
> > we don't have the slave side under control.
> > 
> > Therefore we should really move the OPOST code back to the master side.
> > I'm reluctant to just revert your patch, though, because I think you
> > know better how to fix the OPOST code to make it work correctly on the
> > master side.
> 
> So OPOST processing should be in master side for native windows program.
> However, to solve the second problem I had pointed out in
> http://cygwin.com/ml/cygwin/2015-02/msg00929.html ,
> OPOST processing should be done on a timing when slave calls write().
> 
> To solve this antinomy, I have made a patch attached.
> 
> With this patch, new pipe is introduced to handle OPSOT-process separately
> between native windows program and cygwin program.
> 
> Data from cygwin program is passed through the pipe newly introduced.
> In this case, process_opost_output() is called in fhandler_pty_slave::write().
> Master reads data, which is already applied OPOST process, from the
> new pipe.
> 
> On the other hands, for native windows program, data is written into
> conventional pipe. Master forwarding thread, which is also newly
> introduced, reads conventional pipe and forward the data to the pipe
> newly introduced by calling process_opost_output(). This makes OPOST
> processing be done in master side.
> 
> I have confirmed that the both problem is fixed with this patch.

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?

> By the way,
> I know that the names for the new pipe such as io_handle2, to_master2
> and output_handle2 are ugly enough. Are there more appropriate names?

What about renaming io_handle to io_handle_nat and io_handle2 to io_handle
or io_handle_cyg?


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/20150416/ea186ce5/attachment.sig>


More information about the Cygwin mailing list