Hi Corinna, On Tue, 14 Apr 2015 09:34:56 +0200 Corinna Vinschen <corinna-cyg...@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.y...@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.y...@nifty.ne.jp>
cygwin.patch.20150416-2
Description: Binary data
-- 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
