X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=aUepI90Fk0Lz0dXYNTfQRjnVE/3mm+zoZ0NlJ32XwZLKjHBh4itNt
	WOav/NAQf6EiOxfqxNYXfuswKfFShaZT4BNKc3MWB6yxL3K8/WC9ZLwuYKbN0oWx
	WLo6JQqkx3+1Qj6c0Cbfbj/g1SVSUV/WCws9C1H0MQZAZ1JHYsHhCQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=vPSV3cwIieKIIJpiowuVw9shhP8=; b=b3ZSfJUXN6GDcNbHf0Z+4MU5F6Qi
	1Aj5eEwyP1H1TiP441U1x52xeaWzQgwBSmTk8cq5okxM9aTocIoZkVMEYPIY3ISS
	WqFUiZpKxxeLykmua85nBKFH+OfWoWpGgACTOsj7For3oeqK3lIB40muXqI0ePhG
	vfGpzNA/4SFxbd0=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
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
Date: Mon, 20 Apr 2015 17:12:30 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT 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 AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20150404084354 DOT GX13285 AT calimero DOT vinschen DOT de> <20150405205504 DOT cda3df2cc76f7bca7c3d21fb AT nifty DOT ne DOT jp> <20150407091113 DOT GB2819 AT calimero DOT vinschen DOT de> <20150413193100 DOT a393612bde79a4ae57b8c7d9 AT nifty DOT ne DOT jp> <20150414073456 DOT GY7343 AT calimero DOT vinschen DOT de> <20150416092618 DOT 9975c0e29b8703dbd8d4aa6a AT nifty DOT ne DOT jp> <20150416090533 DOT GB3657 AT calimero DOT vinschen DOT de> <20150417202746 DOT 351d90441d2d41fb316c07a9 AT nifty DOT ne DOT jp> <20150417121052 DOT GY3657 AT calimero DOT vinschen DOT de> <20150420204015 DOT 4b03088d042dcda3774d874b AT nifty DOT ne DOT 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)

--7trrzIZ+323l9a6P
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Apr 20 20:40, Takashi Yano wrote:
> Hi Corinna,
>=20
> On Fri, 17 Apr 2015 14:10:52 +0200
> Corinna Vinschen <corinna-cygwin AT cygwin DOT com> 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 <corinna-cygwin AT cygwin DOT com> 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

-----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--