Mail Archives: cygwin/2015/04/20/11:12:56
--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--
- Raw text -