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=Myg+18A1qtXGju2lKs1IKk/chYVfHXFkNS9u527bECiNYJoUz7jGB
	Xr/ZnoXdFJRrzvHrjPyKJlZZFxcc8c/XPomD35f5ZspG6VTVgQSQFU/AadCvmFHR
	25pUqe6+/GZVnTlHmE76GAbcSJWJNHUsSIUz4j+kKrrOdKDnw4ESGg=
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=X5/HcvZnOkrSHV26WKtwubtp1Tg=; b=rtYYuikaXDqwtV3lZTGGmSlxSEjw
	nD/Phyt4oOkMTu/lrpw0w2UxhmtcY6SGggOPYt0DCFS4X+BvmXbjtvpTwN8KmbiS
	Pk+DCMSEeXYScdto0Tz/ameWaDVNSDFcV5s3hqbN1/sHnqZ+4cikrsFEje6FRfQW
	XKilDkbNMV+bSKA=
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=-4.7 required=5.0 tests=AWL,BAYES_05,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Thu, 16 Apr 2015 11:10:04 +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:	<20150416091004.GA24584@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<20150403130735 DOT d04e41875f7defd0e6c2d8d0 AT nifty DOT ne DOT jp> <20150403113226 DOT GP13285 AT calimero DOT vinschen DOT de> <20150404155520 DOT 8564347f1d42b3c709718aad AT nifty DOT ne DOT jp> <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>
MIME-Version:	1.0
In-Reply-To:	<20150416090533.GB3657@calimero.vinschen.de>
User-Agent:	Mutt/1.5.23 (2014-03-12)

--Dxnq1zWXvFF0Q93v
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Apr 16 11:05, Corinna Vinschen wrote:
> Hi Takashi,
>=20
> On Apr 16 09:26, Takashi Yano wrote:
> > 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 separat=
ely
> > 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::w=
rite().
> > 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.
>=20
> 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?
>=20
> 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?

...and additionally don't have to maintain yet another handle.


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--Dxnq1zWXvFF0Q93v
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVL3xsAAoJEPU2Bp2uRE+gr50P/Rbszmak2cIc277H0P0K4SVj
GAzTV9wDMvquuaGfFm3IlVPifTGOgc2/xpV4lk+ucVxT3vBIMQQSyA2biF1MoOGK
D+/6EnpFmcjaBYVEMUUtQrtpSG1m39OFGDCm6f9LgfRUxIJPlh8hlgDHKEwRDT/F
OMsgtyTbCYLcn/iBXbo53etHL9MIHVr0IF1gqA6DJbi3PwXYz++VWpTFs0+CPmx4
sEHG1JlV0/GkbmIIUOuVKn+UB8FU85Zgmy/UxsQmU6ETQrDJd9Y94ZlfWZrNSRmm
Tn51xf9iMUIHek1qbhddqIQ8r2bQP5a195uZR76+b74ONQZyP7WMT59ULJZME1eg
wNQLt2XgAcV3X3UUT4WaLWvIQOXsHSvEWzEDVmaNR8DeQwi4sYJ78Nrt4EABWLcj
A4VgWdqk3j/igwZOu8pwbu1DE9VZz4cfJ22jr2F8UTKQgWOCXNs9akWsySoEUD0o
9MsqzSEMHS7f1BfJCK5fS9ieLXl2/SA1zfMmEHwACU98JkGLT5ou3xOKwGiBzDNo
py9U2ivUgxYTB2goP1+Hv1vyWL+J8YC74Avyya2hJNkFceQBOVZsmCr1J+mLQCPq
KRWu1Er8u3BTlCDMW2ybl7QQ2iWw5tvnpXqqtLFTULcj0EReR5FcXdDix4A0iC1H
QWWU/NKDMNVbZN+i6Vgv
=EKow
-----END PGP SIGNATURE-----

--Dxnq1zWXvFF0Q93v--

- Raw text -