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:in-reply-to
	:references:mime-version:content-type:content-transfer-encoding;
	q=dns; s=default; b=xD1+qXkCHqGGgoBxC9W6BvCs4ogYo56MmgBzC8vSBNE
	8xUTeFjGR00Jze6ddsu/skrEjgtNom/bROSH8kRmAIaRNCZFDZiWXJDT/GiWK8l3
	6zVywlcr78Q/XwHipeZCoXFEfRnlwIQHh9pP9TaLoUTcrtW2q6Wq1jT1RrbR+XLU
	=
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:in-reply-to
	:references:mime-version:content-type:content-transfer-encoding;
	s=default; bh=Vgb4nznbbTbRDm7gadPI6ehJa+4=; b=Gi5graydyg3tL6gHo
	atOUcNpJLIAZ3HpxkOR+oSpHjByCTEO9Yo2/UwcSO1s+HvAYgnkuF4yzcZT+dwTQ
	oho81tOWVf13VTdB+zzd54m5yKVgB3jlkNYjrlqn9U2rg3ucfKM/g8om2WtGhpTJ
	2LeK+NGDRmkpItlCQUA3jd04ZY=
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=-0.3 required=5.0 tests=AWL,BAYES_50,RCVD_IN_SORBS_DUL,SPF_PASS autolearn=ham version=3.3.2
X-HELO:	conuserg001-v.nifty.com
X-Nifty-SrcIP:	[121.93.68.199]
Date:	Mon, 20 Apr 2015 20:40:15 +0900
From:	Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
To:	cygwin AT cygwin DOT com
Subject:	Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Message-Id:	<20150420204015.4b03088d042dcda3774d874b@nifty.ne.jp>
In-Reply-To:	<20150417121052.GY3657@calimero.vinschen.de>
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> <20150417121052 DOT GY3657 AT calimero DOT vinschen DOT de>
Mime-Version:	1.0
X-IsSubscribed:	yes

Hi Corinna,

On Fri, 17 Apr 2015 14:10:52 +0200
Corinna Vinschen <corinna-cygwin AT cygwin DOT com> 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 = *t;
> >    release_output_mutex ();
> 
> Shouldn't this loop be skipped in TCSANOW mode?

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.

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

You are right. If the slave is only one, both are same. However, they are
quite different when more than one slave exists.

On Fri, 17 Apr 2015 14:25:42 +0200
Corinna Vinschen <corinna-cygwin AT cygwin DOT com> wrote:

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

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.

Furthermore, tcgetattr() should return the latest values set by
tcsetattr(), even if the application of c_oflag is still postponed.

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.

By any chance, my first implementation may be simpler.


-- 
Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -