From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72753 invoked by alias); 16 Apr 2015 09:05:38 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 72743 invoked by uid 89); 16 Apr 2015 09:05:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Apr 2015 09:05:36 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 8CB1CA807DC; Thu, 16 Apr 2015 11:05:33 +0200 (CEST) Date: Thu, 16 Apr 2015 09:05:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Cygwin hangs up if several keys are typed during outputting a lot of texts. Message-ID: <20150416090533.GB3657@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20150305125901.GX3213@calimero.vinschen.de> <20150403130735.d04e41875f7defd0e6c2d8d0@nifty.ne.jp> <20150403113226.GP13285@calimero.vinschen.de> <20150404155520.8564347f1d42b3c709718aad@nifty.ne.jp> <20150404084354.GX13285@calimero.vinschen.de> <20150405205504.cda3df2cc76f7bca7c3d21fb@nifty.ne.jp> <20150407091113.GB2819@calimero.vinschen.de> <20150413193100.a393612bde79a4ae57b8c7d9@nifty.ne.jp> <20150414073456.GY7343@calimero.vinschen.de> <20150416092618.9975c0e29b8703dbd8d4aa6a@nifty.ne.jp> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZoaI/ZTpAVc4A5k6" Content-Disposition: inline In-Reply-To: <20150416092618.9975c0e29b8703dbd8d4aa6a@nifty.ne.jp> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-04/txt/msg00357.txt.bz2 --ZoaI/ZTpAVc4A5k6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3098 Hi Takashi, On Apr 16 09:26, Takashi Yano wrote: > Hi Corinna, >=20 > On Tue, 14 Apr 2015 09:34:56 +0200 > Corinna Vinschen wrote: >=20 > > 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. > >=20 > > 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. > >=20 > > 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. >=20 > 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(). >=20 > To solve this antinomy, I have made a patch attached. >=20 > With this patch, new pipe is introduced to handle OPSOT-process separately > between native windows program and cygwin program. >=20 > Data from cygwin program is passed through the pipe newly introduced. > In this case, process_opost_output() is called in fhandler_pty_slave::wri= te(). > Master reads data, which is already applied OPOST process, from the > new pipe. >=20 > 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. >=20 > 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 --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --ZoaI/ZTpAVc4A5k6 Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVL3tdAAoJEPU2Bp2uRE+gpaYP/1+ZDR2FejyJr9Td/l00Ssyb UkqbcsjTiaTzT6ixxE1QC9yv70sk2NwczUFA9kSfaHPBR1W6ELi7igBJ4KhRspci YPqt32huNpbaNDmKXfjJ1KW0Md8ncU57By143Q7kV9x+AXOS6OBribPMbpv8dRVR hF2lVVlVwVsVR4W4I1jQTj+muT4hOooVUTE1LWwDQRn4VPQlPpoAA70rbYdm2a0V TLS6VcYyNA7p7QRw3d1Yt6gTxSqdrTmSbsVV1RaZ5wSZZsuN4MgcoZ2ruVXWD7se eEb7ek841IgbVYow7wepdzMYxAwmX2uoS7hvzr5ogstFjbyadUVcKFlUS5eFNbmZ UI82QpdD1wzDo8Ib8keXMA2J85jfN2LiD9o7x82G1SXhl/TREmrgZQme81aew2sk /n2xqlUMs/lmhb6Bu26CqmPBsVSc06z6Om5Cnwgdnb07FfzOHyGGGUrmejPH6/wW P+b7S1oWiXRF98w0xIAzxc2/xB5B4h9UFOrIOKRgyLnHqQMyIH0hhRKNPMcAr3wp YFYt55ay6BIsbVi/jgnPhSgoOX439knERbdkq5dHqpu5oLCIMhvh5Sx8pY3fxEZ/ IatOB/3C78XJYULvj7qZole+t268kdJQjsQ1NYtbSQxHqVLLx4CNb25I8sjc+smD 6CwnbnuShKySB0lf6hgB =C+Mm -----END PGP SIGNATURE----- --ZoaI/ZTpAVc4A5k6--