From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96610 invoked by alias); 20 Apr 2015 15:12:35 -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 96535 invoked by uid 89); 20 Apr 2015 15:12:34 -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; Mon, 20 Apr 2015 15:12:33 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 77A91A805A0; Mon, 20 Apr 2015 17:12:30 +0200 (CEST) Date: Mon, 20 Apr 2015 15:12: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: <20150420151230.GS3657@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <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> <20150416090533.GB3657@calimero.vinschen.de> <20150417202746.351d90441d2d41fb316c07a9@nifty.ne.jp> <20150417121052.GY3657@calimero.vinschen.de> <20150420204015.4b03088d042dcda3774d874b@nifty.ne.jp> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7trrzIZ+323l9a6P" Content-Disposition: inline In-Reply-To: <20150420204015.4b03088d042dcda3774d874b@nifty.ne.jp> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-04/txt/msg00468.txt.bz2 --7trrzIZ+323l9a6P Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3040 On Apr 20 20:40, Takashi Yano wrote: > Hi Corinna, >=20 > On Fri, 17 Apr 2015 14:10:52 +0200 > Corinna Vinschen wrote: >=20 > > > @@ -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 =3D *t; > > > release_output_mutex (); > >=20 > > Shouldn't this loop be skipped in TCSANOW mode? >=20 > In Linux (Debian), TCSANOW and TCSADRAIN seem to behave in the same way > for PTY. In other words, both of them do not affect the data already > written, even if master does not read them yet. So I think that skipping > the loop for TCSANOW is not necessary. >=20 > > 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. >=20 > You are right. If the slave is only one, both are same. However, they are > quite different when more than one slave exists. >=20 > On Fri, 17 Apr 2015 14:25:42 +0200 > Corinna Vinschen wrote: >=20 > > Maybe your idea to introduce a second pipe wasn't that bad after all... > >=20 > > 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. > >=20 > > What do you think? >=20 > For implementation of this idea, the application of c_oflag should be > queued and postponed until master-side reads the data written before > tcsetattr(). However, application of other members in struct termios > should not be postponed because they affect PTY input. >=20 > Furthermore, tcgetattr() should return the latest values set by > tcsetattr(), even if the application of c_oflag is still postponed. >=20 > After all, this implementation does not sound also very simple. This > complicated situation is caused because OPOST processing is placed in > master-read-side and it has a delay. >=20 > By any chance, my first implementation may be simpler. Ok. Let's go with that. Can you please rename handle2/master2 to handle_cyg/master_cyg and resend the patch to the cygwin-patches mailing list? Thanks, Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --7trrzIZ+323l9a6P Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVNRdeAAoJEPU2Bp2uRE+gIG4P+gJdGJEAWixjdwYxT5s+RX1s nfazuck4/n9nZpolfqxyI7+TAVbQvJGS8FwLPngsOVQ9jpz6tzJdFlRNdi76JFXe D6Bv6lfjvtB4vQlVOpymQJOSq5EQajKmglT5XAjNEMGxiQr4qQVJsBXjCQX9fyXz lpxzZ5yRfwklkFIMVCzGTKa/8RJEi/WrpGGjBTfwYH+rH2ZfOfTU+ypgzJiQXwu2 mHCom8GhkOdC7smw/KqF3lQlij1qkjhm4z1NElwbvICs6JHGl958VA6Da8HlbRC1 8YdAAeFQCYKF/qQWS2+eghFJFmRiiDEhjbQ2bGpEkAak58c/4UiomvJtpmkjqdmo poj6y7nKMH6s1Lg2RJLRfFig1/rNvq9RK9OXwJx4bRz1B6R1zXpv00fyXrpc6YL2 F/yRfNZ6RrfoQQFRUda+hOdtahig1Tni7eox5tNW0iDwBvWR6am/cZJveUp1G+hI C2zyjSq/ieIns5cGxxbtGsZcPbr+yo761cV6V7aNu/5QAaYKvkq0jY9OUEnGEf/b q1Fe011mqI7TqJxqCkP7KOYmURFOJiiLylfo7oBpAG6GdkH9H0Tl+qVlGDzJaz8L s1lkB16JJJCqRowjpcdnuox9MSHnN6rgBq7E8C4S1sbpH3Pqb228OyIPHyI72Rs8 /VFJ+Vmd0U6+8PrcF9jz =Ebm9 -----END PGP SIGNATURE----- --7trrzIZ+323l9a6P--