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=Fa8vl3XAKh7xH8FSFuN4z8Cp45iGhW/RQxpuOC0ZGUrdgsYsqmoKX
	XAtxdT01UOzyZWrbnvBY4tzIXicxO/AkfU9eb1H29n1Kf0o/X0y95/t+MmVxG/Fv
	GgXkzT+ESap27qG9gUpQwK8ZYtmsJ/iCHxzeRDWje0OPdvCrE2A2C4=
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=dhhuGomcjBq3meRmwu1l/jqOBek=; b=B5Mgwdrcjg2xZCcWOTiH0g3N66ov
	NYMr/VDdIKVba89SESSRbENfl/lslpXifAZfrHpaUmMuLB3g1JzN12W90u9Ux9Hj
	bz4KAbD0g8TGthvtytctK9URRKUWm2COw2/yZX/sKcZ+LAFqWbamZAR3+lHbCKoZ
	OPGBRrDn4gWFct4=
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.5 required=5.0 tests=AWL,BAYES_40,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2
X-HELO: calimero.vinschen.de
Date: Fri, 17 Apr 2015 14:25:42 +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: <20150417122542.GA3657@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <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> <20150417202746 DOT 351d90441d2d41fb316c07a9 AT nifty DOT ne DOT jp> <20150417121052 DOT GY3657 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="6B5oiwbC31sfIr4n"
Content-Disposition: inline
In-Reply-To: <20150417121052.GY3657@calimero.vinschen.de>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Apr 17 14:10, Corinna Vinschen wrote:
> On Apr 17 20:27, Takashi Yano wrote:
> > @@ -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
> > OPOST code has been now completely moved back to master side as
> > with original implementation.
> >=20
> > With this patch, tcsetattr() waits until master reads all data
> > in pipe before new attributes are applied to preserve the order
> > between write() and tcsetattr().
> >=20
> > However, there is a potential risk in which tcsetattr() can be
> > blocked if master stops reading pipe, even though I can not imagine
> > such a likely situation.
>=20
> Yeah, but it is a busy wait.  Hmm.  Also, on second thought, the above
> loop checks for bytes_available every time and changes n.  So, if
> another slave writes lots of data, wouldn't the slave calling tcsetattr
> starve?
>=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
> It would be cool if the slave-side tcsetattr only transmits the
> optional_actions and the new termios content to the master, and the
> master keeps it stashed away together with the number of bytes in the
> pipe right now.  Then in, say, process_slave_output, it checks if the
> precondition is fulfilled and only then overwrites its termios
> structure.
>=20
> Off the top of my head I'm not sure how feasible this is.  One way to do
> that *may* be to send the info in the normal write pipe to the master.
> What we need then would be a method to identify such a tcsetattr packet
> in the input stream.
>=20
> Other ideas?

Maybe your idea to introduce a second pipe wasn't that bad after all...

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.

What do you think?

I'm sorry if I let you jump through hoops here, but I'm not really
sure about the best solution either :}


Corinna

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

--6B5oiwbC31sfIr4n
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJVMPvGAAoJEPU2Bp2uRE+g/CQQAJ5UcExxw6ZOqmSSvtUn9YNh
ayVtGzX/QD03mSL8OK2D9tC9UZuCREnGn13VYTVZv17km/6wzLOOSBH+o2HKfGrn
EpfKuljs1eEyS2GwtZQydyKNbll1Wmhs8EWI6mggvZkYXOBidB67fTTWiwB/63Wn
ZrNmCBwa1h7p/Uhvach/esR2cHSk0WlR8lP0sMfO7jDr7K2VuwbRGsWbZXeOlJIQ
huCXwZd3NLcbhzu13tVtUmS7MH6YgcaHLkCFK89OybSYkwdniHAv+LZOen4OrW73
C3MUC1MSMzXBgks2mLkpx6yRYT4/LyBzExy4GHqg0HwocWPBeskDpBST5L+8LKzL
FAd/lTmhjvEQzpJy5S6PvU8SBArTU0IEsL2o44SETjeqWS2oLs7wXdU0iQV9QCuP
lPwwnCsJiCFyYXMlS1k6RiZqBMMuxWlS5CRPQzX4gCJpJDbwZJoZ47RZxLGeCQdc
tCa+IwD7kX2/w+mhF7Ur7itjQirNoaqrb5KRgIe8tkDui/TyB6WuXQDVLFJQl/g6
POtds0Yh2LZ+in0Yrgf0xNwVigUz3de//SqU8txd3YCoQjiXbM8rj4YMlE3xscUJ
spiYoEwVcNvlucy03ekjCVcSYy37ohUce4mlt26gj9mf35OHUGN1Sox6F+TOApZb
BDcYF1vLm6kqGujQEEp/
=6VDx
-----END PGP SIGNATURE-----

--6B5oiwbC31sfIr4n--