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

[Takashi Yano]

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.

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?


ChangeLog is as follows.


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

	* fhandler.h (class fhandler_base): Add virtual function get_io_handle2
	to get handle from which OPOST-processed output is read on PTY master.
	(class fhandler_pty_slave): Add variable output_handle2 to store handle
	for OPOST-processed output. Add two functions set_output_handle2() and
	get_output_handle2() regarding variable output_handle2. Now,
	output_handle (not 2) is used only by native windows program for
	OPOST-processing in master side. For cygwin process, output_handle2 is
	used for handling OPOST-processing in slave side.
	(class fhandler_pty_master): Add variables io_handle2 and to_master2 to
	store handles for OPOST-processed output. Add pty_master_fwd_thread and
	function pty_master_fwd_thread() for a thread which forwards data from
	io_handle to to_master2 applying OPOST-processing. Add function
	get_io_handle2() regarding variable io_handle2. Now, io_handle and
	to_master are used only by native windows program for OPOST-processing
	in master side. For cygwin process, io_handle2 and to_master2 are used
	for handling OPOST-processing in slave side.
	* fhandler_tty.cc (struct pipe_reply): Add member to_master2.
	(fhandler_pty_master::process_slave_output): Read slave output from
	io_handle2 rather than io_handle.
	(fhandler_pty_slave::fhandler_pty_salve): Initialize output_handle2.
	(fhandler_pty_slave::open): Set output_handle2 by duplicating handle
	to_master2 on PTY master.
	(fhandler_pty_slave::close): Close handle output_handle2.
	(fhandler_pty_slave::write): Write data to output_handle2 rather than
	output_handle.
	(fhandler_pty_slave::fch_close_handles): Close handle output_handle2.
	(fhandler_pty_master::fhandler_pty_master): Initialize io_handle2,
	to_master2 and master_fwd_thread.
	(fhandler_pty_master::cleanup): Clean up to_master2 as well.
	(fhandler_pty_master::close): Print to_master2 as well in debug
	message. Terminate master forwarding thread. Close handles to_master2
	and io_handle2.
	(fhandler_pty_master::ioctl): Use io_handle2 rather than to_master.
	(fhandler_pty_master::pty_master_thread): Add code for duplicating
	handle to_master2.
	(fhandler_pty_master::pty_master_fwd_thread): New function for
	a thread to forward OPOST-processed data from io_handle to to_master2.
	This thread applies OPOST-processing to the output of native windows
	program.
	(::pty_master_fwd_thread): Ditto.
	(fhandler_pty_master::setup): Create new pipe for OPOST-processed
	output. Create new thread to forward data from io_handle to to_master2.
	Set handle to_master2 to tty. Print io_handle2 as well in debug message.
	Close handles io_handle2 and to_master2 in case of error.
	(fhandler_pty_master::fixup_after_fork): Set handle to_master2 to tty.
	Copy handle to_master2 from arch->to_master2.
	(fhandler_pty_master::fixup_after_exec): Clean up to_master2.
	* select.cc: Check handle returned by get_io_handle2() rather than
	get_handle().
	* tty.h(class tty): Add variable _to_master2 to store handle to which
	OPOST-processed data is written. Add two functions to_master2() and
	set_to_master2() regarding _to_master2.


-- 
Takashi Yano <takashi.yano@nifty.ne.jp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygwin.patch.20150416-2
Type: application/octet-stream
Size: 13939 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20150416/6290fa9a/attachment.obj>
-------------- next part --------------
--
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