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