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=dEcnr9vT65Qmu9LXHVRiwyTnPJH3twWdoLDyRpbLTf3yWsMSh+mHs
	7whZQ57irj4vT1bhyH5DuIeluBgbYu1xXisH375jMNO6jb4e+E/JG6TKDNKXaePX
	cQfM8dUQisiec94TPgtfZ7w9G2Z4EA4/5ZCBUYg8TM9I7OGqrRs7Jc=
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=bFZvhWsFR4cRCe2yMQa0AzfH67U=; b=KbabPNNC9IE/X88h+cXONj33DghN
	ZIYzmzLO/CXxXOSIab+Gtfl/CYGkIb/HREPFxMSPfegICMdMU/XBXDReuFx6hrAC
	hPgGvSW+ad6niENQuRqQUfKenGCpMeSwucCQPK9vds+AdeMMKRu+2+xrwTTABPzR
	5N+h+sSLoGdjj8w=
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: Fri, 17 Apr 2015 14:10:52 +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: <20150417121052.GY3657@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <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> <20150417202746 DOT 351d90441d2d41fb316c07a9 AT nifty DOT ne DOT jp>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="9AazSAFPVKSPmRXK"
Content-Disposition: inline
In-Reply-To: <20150417202746.351d90441d2d41fb316c07a9@nifty.ne.jp>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

Hi Takashi,

On Apr 17 20:27, Takashi Yano wrote:
> Hi Corinna,
>=20
> On Thu, 16 Apr 2015 11:05:33 +0200
> Corinna Vinschen <corinna-cygwin AT cygwin DOT com> wrote:
>=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?
>=20
> I also think the patch was a big deal. However, I did not have
> any other good idea.
>=20
> Anyway, I have worked out another solution. Please find a patch
> attached.
>=20
> What do you think of this one?

Looks better to me.   However:

> @@ -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 ();

Shouldn't this loop be skipped in TCSANOW mode?

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

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?

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.

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.

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.

Other ideas?


Thanks,
Corinna

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

--9AazSAFPVKSPmRXK
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJVMPhMAAoJEPU2Bp2uRE+gnO0P/jyWDJ2CYw0N61i7SppR4SZo
y3SImNnteCRqmmiOac/NhP7FnjevGNSKQIjT7ZsG1TABEhbtMobLgR7SqF7J48XS
yngtS16JEJfD8DgfKQReMNqr3BvWwJnNRLessn+ZosJFfz0ENybkJUszcpAEhFOq
Og9D2WTFjw5uPqdhtFhEIlucyvUwpMPFYI4W2wmpOngqEUjJgBcpA7/1LUwAaSLe
gsUCmckCDOPWpp1YJj7Cy5VxpWXoI88OkYWZ63JSbzx3YaMAUaRDI9AF/66qdiB6
ULjpjl5Ast/2vywIxf6KEe82K2i0A8dVHFPqZDnUP51cK1f7umUn0/mEkDS9NQTU
1MF5YNYL33LXhKdkvx6u1MmirqSGRsKE4whLhMXVwfJL/TUnwP0LSoSSCVpFz0ru
2SkEbdcgzcgBeMi/WwE8aPmpDnCAzbBa+ysYjFyDxqKLm7doj9a+xH9qPUdnRbYw
OvafLOYWvXpsQ0Xh2I9BEnfxYKo3t/8mkZBUaYbHHDUfL0XfPE3EfnUxqFqZDcmx
3ajEqyW1vD9W4X/UCXnzXfdmsTBTWJijE5/ic1O+g2iYBTdmfozQUOcRrbptPnM0
SRh9FPJSzLQBkLL/EqJj2J4q0Qa4GGwgKr3iUo3Md9TNe6dQy17ad7wlEontaNNE
A4GS8x1yHuDlr733q+5a
=YVEh
-----END PGP SIGNATURE-----

--9AazSAFPVKSPmRXK--