Mail Archives: cygwin/2015/04/17/08:11:14
--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--
- Raw text -