On Apr 20 20:40, Takashi Yano wrote:
> Hi Corinna,
>
> On Fri, 17 Apr 2015 14:10:52 +0200
> Corinna Vinschen <corinna-cyg...@cygwin.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-cyg...@cygwin.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.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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgphaSFLMVkFz.pgp
Description: PGP signature
