Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Corinna, On Mon, 20 Apr 2015 17:12:30 +0200 Corinna Vinschen corinna-cyg...@cygwin.com wrote: 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? Please find a patch attached. ChangeLog is as follows. 2015-04-22 Takashi Yano takashi.y...@nifty.ne.jp * fhandler.h (class fhandler_base): Add virtual function get_io_handle_cyg() to get handle from which OPOST-processed output is read on PTY master. (class fhandler_pty_slave): Add variable output_handle_cyg to store a handle to which OPOST-processed output is written. Add two functions, i.e., set_output_handle_cyg() and get_output_handle_cyg(), regarding variable output_handle_cyg. Now, output_handle is used only by native windows program. The data before OPOST-processing is written to output_handle and OPOST-processing is applied in the master-side. For a cygwin process, OPOST-processing is applied in the slave-side, and the data after OPOST-processing is written to output_handle_cyg. (class fhandler_pty_master): Add two variables, i.e., io_handle_cyg and to_master_cyg, to store handles of a pipe through which OPOST-processed output passes. Add pty_master_fwd_thread and function pty_master_fwd_thread() for a thread which applies OPOST-processing and forwards data from io_handle to to_master_cyg. Add function get_io_handle_cyg() regarding variable io_handle_cyg. Now, the pipe between io_handle and to_master are used only by native windows program for applying OPOST-processing in the master-side. For a cygwin process, the pipe between io_handle_cyg and to_master_cyg is used for passing through the data which is applied OPOST-processing in the slave-side. * fhandler_tty.cc (struct pipe_reply): Add member to_master_cyg. (fhandler_pty_master::process_slave_output): Read slave output from io_handle_cyg rather than io_handle. (fhandler_pty_slave::fhandler_pty_salve): Initialize output_handle_cyg. (fhandler_pty_slave::open): Set output_handle_cyg by duplicating handle to_master_cyg on PTY master. (fhandler_pty_slave::close): Close handle output_handle_cyg. (fhandler_pty_slave::write): Write data to output_handle_cyg rather than output_handle. (fhandler_pty_slave::fch_close_handles): Close handle output_handle_cyg. (fhandler_pty_master::fhandler_pty_master): Initialize io_handle_cyg, to_master_cyg and master_fwd_thread. (fhandler_pty_master::cleanup): Clean up to_master_cyg as well. (fhandler_pty_master::close): Print to_master_cyg as well in debug message. Terminate master forwarding thread. Close handles to_master_cyg and io_handle_cyg. (fhandler_pty_master::ioctl): Use io_handle_cyg rather than to_master. (fhandler_pty_master::pty_master_thread): Add code for duplicating handle to_master_cyg. (fhandler_pty_master::pty_master_fwd_thread): New function for a thread to forward OPOST-processed data from io_handle to to_master_cyg. This thread applies OPOST-processing to the output of native windows program. (::pty_master_fwd_thread): Ditto. (fhandler_pty_master::setup): Create a new pipe to pass thruegh OPOST- processed output. Create new thread to forward data from io_handle to to_master_cyg. Set handle to_master_cyg to tty. Print io_handle_cyg as well in debug message. Close handles io_handle_cyg and to_master_cyg in case of error. (fhandler_pty_master::fixup_after_fork): Set handle to_master_cyg to tty. Copy handle to_master_cyg from arch-to_master_cyg. (fhandler_pty_master::fixup_after_exec): Clean up to_master_cyg. * select.cc: Check handle returned by get_io_handle_cyg() rather than get_handle(). * tty.h (class tty): Add variable _to_master_cyg to store a handle to which OPOST-processed data is written. Add two functions, to_master_cyg() and set_to_master_cyg(), regarding _to_master_cyg. -- Takashi Yano takashi.y...@nifty.ne.jp cygwin.patch.20150422-2 Description: Binary data
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
On Apr 22 19:57, Takashi Yano wrote: Hi Corinna, On Mon, 20 Apr 2015 17:12:30 +0200 Corinna Vinschen corinna-cyg...@cygwin.com wrote: 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? Please find a patch attached. ChangeLog is as follows. Patch applied, thank you. Additionally I fixed a long-standing problem in fhandler_pty_slave::fch_close_handles. It closes handles not previously opened by fch_open_handles. I didn't relaize this until I saw your patch. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpxa8E22Jh44.pgp Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
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.
--
Takashi Yano takashi.y...@nifty.ne.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
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
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
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Corinna, On Thu, 16 Apr 2015 11:05:33 +0200 Corinna Vinschen corinna-cyg...@cygwin.com wrote: 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? 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? I also think the patch was a big deal. However, I did not have any other good idea. Anyway, I have worked out another solution. Please find a patch attached. What do you think of this one? OPOST code has been now completely moved back to master side as with original implementation. 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(). 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. Moreover, it is necessary to duplicate io_handle from master-side to slave-side to allow slave to peek master pipe. It is not smart enough, I suppose. ChageLog is as follows. 2015-04-17 Takashi Yano takashi.y...@nifty.ne.jp * fhandler.h (fhandler_pty_common): Remove function process_opost_output (). Since processing regarding OPOST is moved back to master side, this function is needed no more. (class fhandler_pty_slave): Add variable 'from_slave' for checking whether master input pipe is empty. This used by flandler_pty_slave ::tcsetattr(). (class fhandler_pty_master): Move variable 'column' for handling ONOCR from class tty to class fhandler_pty_master. Revive variable 'need_nl' which is used by OPOST-processing in master side. * fhandler_tty.cc (struct pipe_reply): Add member 'from_slave'. (fhandler_pty_master::doecho): Call WriteFile() instead of fhandler_pty_common::process_opost_output(). (fhandler_pty_master::process_slave_output): Move OPOST-processing back into this function. (fhandler_pty_slave::fhandler_pty_slave): Initialize 'from_slave'. (fhandler_pty_slave::open): Duplicate handle regarding 'from_slave'. (fhandler_pty_slave::close): Close handle 'from_slave'. (fhandler_pty_slave::write): Call WriteFile() instead of fhandler_pty_common::process_opost_output(). (fhandler_pty_slave::tcsetattr): Wait until master reads all data from slave. (fhandler_pty_slave::fhandler_pty_slave): Initialize 'column' and 'need_nl'. (fhandler_pty_master::pty_master_thread): Add code to duplicate handle regarding 'from_slave'. (fhandler_pty_master::setup): Set io_handle to tty::_from_slave. (fhandler_pty_common::process_opost_output): Remove this function. * select.cc (peek_pipe): Revive the code checking 'need_nl'. * tty.cc (tty::init): Remove initialization for 'column'. * tty.h (class tty): Add variable '_from_slave'. Add two functions from_slave() and set_from_slave() regarding '_from_master'. Remove variable 'column'. It is moved to class fhandler_pty_master. -- Takashi Yano takashi.y...@nifty.ne.jp cygwin.patch.20150417-2 Description: Binary data -- 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
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
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 = *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.
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().
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?
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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpb_IFuYzXpC.pgp
Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Takashi,
On Apr 17 20:27, Takashi Yano wrote:
Hi Corinna,
On Thu, 16 Apr 2015 11:05:33 +0200
Corinna Vinschen corinna-cyg...@cygwin.com wrote:
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?
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?
I also think the patch was a big deal. However, I did not have
any other good idea.
Anyway, I have worked out another solution. Please find a patch
attached.
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 = *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.
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().
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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpIA8ijrlWUs.pgp
Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Takashi, On Apr 16 09:26, Takashi Yano wrote: Hi Corinna, On Tue, 14 Apr 2015 09:34:56 +0200 Corinna Vinschen corinna-cyg...@cygwin.com wrote: And the native client, not knowing what he's talking to, recognizes the output stream as a normal named pipe, if it's looking for that info at all. Being native, it will use native Windows MSVCRT stdio calls. Worse, as you can see in the behaviour of some native applications, the MSVCRT isatty() call returns 0 for named pipes. If we have a Cygwin client, we can do all kinds of stuff on the slave side, but as soon as we have a native client, only the master side of the pty has any chance to do the right thing. That's why I wrote that we don't have the slave side under control. Therefore we should really move the OPOST code back to the master side. I'm reluctant to just revert your patch, though, because I think you know better how to fix the OPOST code to make it work correctly on the master side. So OPOST processing should be in master side for native windows program. However, to solve the second problem I had pointed out in http://cygwin.com/ml/cygwin/2015-02/msg00929.html , OPOST processing should be done on a timing when slave calls write(). To solve this antinomy, I have made a patch attached. With this patch, new pipe is introduced to handle OPSOT-process separately between native windows program and cygwin program. Data from cygwin program is passed through the pipe newly introduced. In this case, process_opost_output() is called in fhandler_pty_slave::write(). Master reads data, which is already applied OPOST process, from the new pipe. On the other hands, for native windows program, data is written into conventional pipe. Master forwarding thread, which is also newly introduced, reads conventional pipe and forward the data to the pipe newly introduced by calling process_opost_output(). This makes OPOST processing be done in master side. I have confirmed that the both problem is fixed with this patch. 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? 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? By the way, I know that the names for the new pipe such as io_handle2, to_master2 and output_handle2 are ugly enough. Are there more appropriate names? What about renaming io_handle to io_handle_nat and io_handle2 to io_handle or io_handle_cyg? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgppfkijLvlXr.pgp Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
On Apr 16 11:05, Corinna Vinschen wrote: Hi Takashi, On Apr 16 09:26, Takashi Yano wrote: So OPOST processing should be in master side for native windows program. However, to solve the second problem I had pointed out in http://cygwin.com/ml/cygwin/2015-02/msg00929.html , OPOST processing should be done on a timing when slave calls write(). To solve this antinomy, I have made a patch attached. With this patch, new pipe is introduced to handle OPSOT-process separately between native windows program and cygwin program. Data from cygwin program is passed through the pipe newly introduced. In this case, process_opost_output() is called in fhandler_pty_slave::write(). Master reads data, which is already applied OPOST process, from the new pipe. On the other hands, for native windows program, data is written into conventional pipe. Master forwarding thread, which is also newly introduced, reads conventional pipe and forward the data to the pipe newly introduced by calling process_opost_output(). This makes OPOST processing be done in master side. I have confirmed that the both problem is fixed with this patch. 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? 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? ...and additionally don't have to maintain yet another handle. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp59Iw96jJ4_.pgp Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Corinna, On Tue, 14 Apr 2015 09:34:56 +0200 Corinna Vinschen corinna-cyg...@cygwin.com wrote: And the native client, not knowing what he's talking to, recognizes the output stream as a normal named pipe, if it's looking for that info at all. Being native, it will use native Windows MSVCRT stdio calls. Worse, as you can see in the behaviour of some native applications, the MSVCRT isatty() call returns 0 for named pipes. If we have a Cygwin client, we can do all kinds of stuff on the slave side, but as soon as we have a native client, only the master side of the pty has any chance to do the right thing. That's why I wrote that we don't have the slave side under control. Therefore we should really move the OPOST code back to the master side. I'm reluctant to just revert your patch, though, because I think you know better how to fix the OPOST code to make it work correctly on the master side. So OPOST processing should be in master side for native windows program. However, to solve the second problem I had pointed out in http://cygwin.com/ml/cygwin/2015-02/msg00929.html , OPOST processing should be done on a timing when slave calls write(). To solve this antinomy, I have made a patch attached. With this patch, new pipe is introduced to handle OPSOT-process separately between native windows program and cygwin program. Data from cygwin program is passed through the pipe newly introduced. In this case, process_opost_output() is called in fhandler_pty_slave::write(). Master reads data, which is already applied OPOST process, from the new pipe. On the other hands, for native windows program, data is written into conventional pipe. Master forwarding thread, which is also newly introduced, reads conventional pipe and forward the data to the pipe newly introduced by calling process_opost_output(). This makes OPOST processing be done in master side. I have confirmed that the both problem is fixed with this patch. By the way, I know that the names for the new pipe such as io_handle2, to_master2 and output_handle2 are ugly enough. Are there more appropriate names? ChangeLog is as follows. 2015-04-16 Takashi Yano takashi.y...@nifty.ne.jp * fhandler.h (class fhandler_base): Add virtual function get_io_handle2 to get handle from which OPOST-processed output is read on PTY master. (class fhandler_pty_slave): Add variable output_handle2 to store handle for OPOST-processed output. Add two functions set_output_handle2() and get_output_handle2() regarding variable output_handle2. Now, output_handle (not 2) is used only by native windows program for OPOST-processing in master side. For cygwin process, output_handle2 is used for handling OPOST-processing in slave side. (class fhandler_pty_master): Add variables io_handle2 and to_master2 to store handles for OPOST-processed output. Add pty_master_fwd_thread and function pty_master_fwd_thread() for a thread which forwards data from io_handle to to_master2 applying OPOST-processing. Add function get_io_handle2() regarding variable io_handle2. Now, io_handle and to_master are used only by native windows program for OPOST-processing in master side. For cygwin process, io_handle2 and to_master2 are used for handling OPOST-processing in slave side. * fhandler_tty.cc (struct pipe_reply): Add member to_master2. (fhandler_pty_master::process_slave_output): Read slave output from io_handle2 rather than io_handle. (fhandler_pty_slave::fhandler_pty_salve): Initialize output_handle2. (fhandler_pty_slave::open): Set output_handle2 by duplicating handle to_master2 on PTY master. (fhandler_pty_slave::close): Close handle output_handle2. (fhandler_pty_slave::write): Write data to output_handle2 rather than output_handle. (fhandler_pty_slave::fch_close_handles): Close handle output_handle2. (fhandler_pty_master::fhandler_pty_master): Initialize io_handle2, to_master2 and master_fwd_thread. (fhandler_pty_master::cleanup): Clean up to_master2 as well. (fhandler_pty_master::close): Print to_master2 as well in debug message. Terminate master forwarding thread. Close handles to_master2 and io_handle2. (fhandler_pty_master::ioctl): Use io_handle2 rather than to_master. (fhandler_pty_master::pty_master_thread): Add code for duplicating handle to_master2. (fhandler_pty_master::pty_master_fwd_thread): New function for a thread to forward OPOST-processed data from io_handle to to_master2. This thread applies OPOST-processing to the output of native windows program. (::pty_master_fwd_thread): Ditto. (fhandler_pty_master::setup): Create new pipe for OPOST-processed output. Create new thread to forward data from io_handle to to_master2.
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Takashi, On Apr 13 19:31, Takashi Yano wrote: Hi Corinna, I'm sorry for late reply. No worries. On Tue, 7 Apr 2015 11:11:13 +0200 Corinna Vinschen corinna-cyg...@cygwin.com wrote: I think we should move opost processing back to the master side. Would it be much of a problem to restructure your patch to do that, without re-introducing the old problems your patch fixed? I am considering of this issue for several days. However, it is still with dificulty. For my better understanding, may I ask a question? At where does cygwin set the standard output handle for native windows programs to fhandler_pty_slave:: output_handle? It doesn't. The only way to set a handle for a native client is by propagating the handle via execve. And the native client, not knowing what he's talking to, recognizes the output stream as a normal named pipe, if it's looking for that info at all. Being native, it will use native Windows MSVCRT stdio calls. Worse, as you can see in the behaviour of some native applications, the MSVCRT isatty() call returns 0 for named pipes. If we have a Cygwin client, we can do all kinds of stuff on the slave side, but as soon as we have a native client, only the master side of the pty has any chance to do the right thing. That's why I wrote that we don't have the slave side under control. Therefore we should really move the OPOST code back to the master side. I'm reluctant to just revert your patch, though, because I think you know better how to fix the OPOST code to make it work correctly on the master side. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpHRcTSMF0lz.pgp Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Corinna, I'm sorry for late reply. On Tue, 7 Apr 2015 11:11:13 +0200 Corinna Vinschen corinna-cyg...@cygwin.com wrote: I think we should move opost processing back to the master side. Would it be much of a problem to restructure your patch to do that, without re-introducing the old problems your patch fixed? I am considering of this issue for several days. However, it is still with dificulty. For my better understanding, may I ask a question? At where does cygwin set the standard output handle for native windows programs to fhandler_pty_slave:: output_handle? Since I found SetStdHandle() calls in dtable.cc, I tried to disable all of them. However, the output of icacls still appears in mintty screen. I wonder where the standard output handle is set. By the way, Hmm, even after cbb9849fa76f1dbe6c66d91b68d9a10f46f1ba69, it does not work in my environment. this problem has been gone after the following change. commit 72f7cd89f230342107ec9e22fea38bf75bcb698d Author: Jon TURNEY jon.tur...@dronecode.org.uk Date: Sat Apr 4 23:31:03 2015 +0100 Compile exceptions.cc with -fno-omit-frame-pointer on x86 Selectively using -fomit-frame-pointer when -O is used doesn't make sense anymore, apparently since gcc 4.6, -O implies -fomit-frame-pointer. exceptions.cc must be compiled with -fno-omit-frame-pointer on x86, as it uses RtlCaptureContext, which requires a frame pointer. * Makefile.in : Remove setting -fomit-frame-pointer for compiling various files, it is already the default. Set -fno-omit-frame-pointer for exceptions.cc on x86. Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk -- Takashi Yano takashi.y...@nifty.ne.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
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Takashi,
On Apr 5 20:55, Takashi Yano wrote:
Hi Corinna,
On Sat, 4 Apr 2015 10:43:54 +0200
Corinna Vinschen corinna-cyg...@cygwin.com wrote:
That should have been fixed by cbb9849fa76f1dbe6c66d91b68d9a10f46f1ba69.
You have to rebuild Cygwin to make this change have an effect.
Alternatively you could checkout f992ae6f4da99b6a200cfc146b96e8e921ca1e70
to ignore the ucontext stuff for now.
Hmm, even after cbb9849fa76f1dbe6c66d91b68d9a10f46f1ba69,
it does not work in my environment.
But ok, f992ae6f4da99b6a200cfc146b96e8e921ca1e70 works.
Using f992ae6f4da99b6a200cfc146b96e8e921ca1e70, the problem
you had pointed out has been regenerated. Same problem can
be regenerated with a simple test case below.
#include windows.h
int main()
{
HANDLE hCons;
DWORD n;
hCons = GetStdHandle(STD_OUTPUT_HANDLE);
WriteFile(hCons, \n, 5, n, NULL);
WriteFile(hCons, \n, 5, n, NULL);
WriteFile(hCons, \n, 5, n, NULL);
CloseHandle(hCons);
return 0;
}
This is caused obviously by the patch I had proposed.
Post processing, in which \n is converted to \r\n, was in
the read process previously, so it had effect to the test
case above.
However, now the post processing is in the write process,
so it does not have effect against direct WriteFile() to
the pipe.
Unfortunately, I have no idea for the moment
The problem is that the patch shifted processing from the pty master to
the slave, but the slave isn't necessarily a well-behaved Cygwin process.
I think we should move opost processing back to the master side. Would
it be much of a problem to restructure your patch to do that, without
re-introducing the old problems your patch fixed?
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgp_3KX6zin_M.pgp
Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Corinna,
On Sat, 4 Apr 2015 10:43:54 +0200
Corinna Vinschen corinna-cyg...@cygwin.com wrote:
That should have been fixed by cbb9849fa76f1dbe6c66d91b68d9a10f46f1ba69.
You have to rebuild Cygwin to make this change have an effect.
Alternatively you could checkout f992ae6f4da99b6a200cfc146b96e8e921ca1e70
to ignore the ucontext stuff for now.
Hmm, even after cbb9849fa76f1dbe6c66d91b68d9a10f46f1ba69,
it does not work in my environment.
But ok, f992ae6f4da99b6a200cfc146b96e8e921ca1e70 works.
Using f992ae6f4da99b6a200cfc146b96e8e921ca1e70, the problem
you had pointed out has been regenerated. Same problem can
be regenerated with a simple test case below.
#include windows.h
int main()
{
HANDLE hCons;
DWORD n;
hCons = GetStdHandle(STD_OUTPUT_HANDLE);
WriteFile(hCons, \n, 5, n, NULL);
WriteFile(hCons, \n, 5, n, NULL);
WriteFile(hCons, \n, 5, n, NULL);
CloseHandle(hCons);
return 0;
}
This is caused obviously by the patch I had proposed.
Post processing, in which \n is converted to \r\n, was in
the read process previously, so it had effect to the test
case above.
However, now the post processing is in the write process,
so it does not have effect against direct WriteFile() to
the pipe.
Unfortunately, I have no idea for the moment
--
Takashi Yano takashi.y...@nifty.ne.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
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
On Apr 4 15:55, Takashi Yano wrote: Hi Corinna, On Fri, 3 Apr 2015 13:32:26 +0200 Corinna Vinschen corinna-cyg...@cygwin.com wrote: Btw., we have a regression in the latest PTY code in terms of some native Windows tools. I noticed this with `icacls': To confirm this, I tried to build latest git version. However, I have found that cygwin1.dll built above does not work at all for me. With new cygwin1.dll, mintty keeps black screen, i.e. no prompt appears. It seems that this occurs after the following change. That should have been fixed by cbb9849fa76f1dbe6c66d91b68d9a10f46f1ba69. You have to rebuild Cygwin to make this change have an effect. Alternatively you could checkout f992ae6f4da99b6a200cfc146b96e8e921ca1e70 to ignore the ucontext stuff for now. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpBHCgkkSXdY.pgp Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Corinna, On Fri, 3 Apr 2015 13:32:26 +0200 Corinna Vinschen corinna-cyg...@cygwin.com wrote: Btw., we have a regression in the latest PTY code in terms of some native Windows tools. I noticed this with `icacls': To confirm this, I tried to build latest git version. However, I have found that cygwin1.dll built above does not work at all for me. With new cygwin1.dll, mintty keeps black screen, i.e. no prompt appears. It seems that this occurs after the following change. Is replacing cygwin1.dll insufficient after this change? commit 28e457cd717d630d6ac13dba7b8f2a162156effb Author: Jon TURNEY jon.tur...@dronecode.org.uk Date: Mon Mar 30 20:31:13 2015 +0100 Provide ucontext to signal handlers Add ucontext.h header, defining ucontext_t and mcontext_t types. Provide sigaction sighandlers with a ucontext_t parameter, containing stack and context information. * include/sys/ucontext.h : New header. * include/ucontext.h : Ditto. * exceptions.cc (call_signal_handler): Provide ucontext_t parameter to signal handler function. Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk -- Takashi Yano takashi.y...@nifty.ne.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
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Takashi, On Apr 3 13:07, Takashi Yano wrote: On Thu, 5 Mar 2015 13:59:01 +0100 Corinna Vinschen corinna-cyg...@cygwin.com wrote: One small thing to be improved is here: + if (echo_cnt 0 +ReadFile (echo_r, outbuf, MIN (rlen, echo_cnt), n, NULL)) echo_cnt returned by ::bytes_available() is actually not a number of bytes available in the pipe. This is because ::bytes_available() returns nleft instead of navail when nleft is non-zero. Therefore, rlen should be used here rather than MIN (rlen, echo_cnt). Thanks, done. I applied the patch now with two additional changes for better error handling. For the same reason, I propose the following patch. 2015-04-03 Takashi Yano takashi.y...@nifty.ne.jp * fhandler_tty.cc (fhandler_pty_slave::read): Change calculation of readlen not to use bytes_in_pype value directly. Thanks, patch applied. Btw., we have a regression in the latest PTY code in terms of some native Windows tools. I noticed this with `icacls': With Cygwin 1.7.35: $ icacls xxx xxx VINSCHEN\corinna:(W,D,Rc,WDAC,WO,X,DC,RA) VINSCHEN\vinschen:(W,Rc,X,DC,RA) Everyone:(W,Rc,X,DC,RA) Successfully processed 1 files; Failed processing 0 files With git HEAD: $ icacls xxx xxx VINSCHEN\corinna:(W,D,Rc,WDAC,WO,X,DC,RA) VINSCHEN\vinschen:(W,Rc,X,DC,RA) Everyone:(W,Rc,X,DC,RA) Successfully processed 1 files; Failed processing 0 files This does not occur in a Windows console window, so it seems this has been introduced by the PTY changes. If you look into the output generated by icacls, you'll notice that it only generates POSIXy LF line endings, not Windowsy CRLF. The CRs required to generate correct output are missing now for some reason, but only for native, non-Cygwin clients. Would you mind to have a look into this issue? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpdPAGS5_Ht6.pgp Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
On Thu, 5 Mar 2015 13:59:01 +0100 Corinna Vinschen corinna-cyg...@cygwin.com wrote: One small thing to be improved is here: + if (echo_cnt 0 + ReadFile (echo_r, outbuf, MIN (rlen, echo_cnt), n, NULL)) echo_cnt returned by ::bytes_available() is actually not a number of bytes available in the pipe. This is because ::bytes_available() returns nleft instead of navail when nleft is non-zero. Therefore, rlen should be used here rather than MIN (rlen, echo_cnt). Thanks, done. I applied the patch now with two additional changes for better error handling. For the same reason, I propose the following patch. 2015-04-03 Takashi Yano takashi.y...@nifty.ne.jp * fhandler_tty.cc (fhandler_pty_slave::read): Change calculation of readlen not to use bytes_in_pype value directly. diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc index 89cc9e5..daa24eb 100644 --- a/winsup/cygwin/fhandler_tty.cc +++ b/winsup/cygwin/fhandler_tty.cc @@ -742,7 +742,7 @@ fhandler_pty_slave::read (void *ptr, size_t len) return; } - readlen = MIN (bytes_in_pipe, MIN (len, sizeof (buf))); + readlen = bytes_in_pipe ? MIN (len, sizeof (buf)) : 0; #if 0 /* Why on earth is the read length reduced to vmin, even if more bytes -- Takashi Yano takashi.y...@nifty.ne.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
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
On Fri, 3 Apr 2015 13:07:35 +0900 Takashi Yano takashi.y...@nifty.ne.jp wrote: 2015-04-03 Takashi Yano takashi.y...@nifty.ne.jp * fhandler_tty.cc (fhandler_pty_slave::read): Change calculation of readlen not to use bytes_in_pype value directly. s/pype/pipe/ Sorry. -- Takashi Yano takashi.y...@nifty.ne.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
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
On Mar 5 20:24, Takashi Yano wrote: On Wed, 4 Mar 2015 19:18:57 +0100 Corinna Vinschen corinna-cyg...@cygwin.com wrote: The result is the patch I attached to this mail. I'm not sure it's the most feasible way to solve this problem, but it works pretty nicely for me, including pasting big chunks (I tried a clipboard with about 70K of data) while yes(1) is running. Thank you, Corinna. I have tried your patch. It nicely works for me, too. And your workaround is definitely better than mine. One small thing to be improved is here: + if (echo_cnt 0 +ReadFile (echo_r, outbuf, MIN (rlen, echo_cnt), n, NULL)) echo_cnt returned by ::bytes_available() is actually not a number of bytes available in the pipe. This is because ::bytes_available() returns nleft instead of navail when nleft is non-zero. Therefore, rlen should be used here rather than MIN (rlen, echo_cnt). Thanks, done. I applied the patch now with two additional changes for better error handling. By the way, should we go to cygwin-developer mailing list? Nah, not for this one. For the next bigger issue, that would be nice, especially if you come up with code and stuff :) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpfuYc1omIlJ.pgp Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
On Wed, 4 Mar 2015 19:18:57 +0100 Corinna Vinschen corinna-cyg...@cygwin.com wrote: The result is the patch I attached to this mail. I'm not sure it's the most feasible way to solve this problem, but it works pretty nicely for me, including pasting big chunks (I tried a clipboard with about 70K of data) while yes(1) is running. Thank you, Corinna. I have tried your patch. It nicely works for me, too. And your workaround is definitely better than mine. One small thing to be improved is here: + if (echo_cnt 0 + ReadFile (echo_r, outbuf, MIN (rlen, echo_cnt), n, NULL)) echo_cnt returned by ::bytes_available() is actually not a number of bytes available in the pipe. This is because ::bytes_available() returns nleft instead of navail when nleft is non-zero. Therefore, rlen should be used here rather than MIN (rlen, echo_cnt). By the way, should we go to cygwin-developer mailing list? -- Takashi Yano takashi.y...@nifty.ne.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
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
On Mar 4 19:18, Corinna Vinschen wrote: Hi Takashi, Oh, btw. I wouldn't be too unhappy if we could move the discussions about Cygwin implementation details to the cygwin-developers mailing list. The cygwin mailing list should be reserved for the more user-centric stuff, me thinks. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpWDAK_zs6co.pgp Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Takashi,
On Mar 4 13:19, Corinna Vinschen wrote:
On Mar 4 20:34, Takashi Yano wrote:
On Mon, 2 Mar 2015 15:44:26 +0100
Corinna Vinschen corinna-cyg...@cygwin.com wrote:
To check buffer space before WriteFile() is one idea,
but it is not smart, I suppose...
I think that's not it. [blah...]
[...]
As a result of the test, it has become clear that this
modification conceals the problem. This means the problem
is closely related to occupancy of buffer.
Now, I suppose the cause has been clarified. So we have
to work out a solution. How can we resolve this problem?
I'm not sure. I still have to look deeper into that. Locally
I treid to woraround this problem by calling WriteFile overlapped
without waiting for the result, but even that doesn't work.
Ok, the good news is, I have a potential workaround for this problem.
The bad news is, it might be just a bad hack.
The problem is apparently that the slave fills up the to_master buffer.
If the master doesn't constantly and fastly read the slave output, the
slave will hang a lot in the WriteFile call and the pipe buffer is most
of the time full. When the master itself calls doecho, it has a rather
high probability that the slave is in a WriteFile call. The master will
hang in acquire_output_mutex while the slave hangs in WriteFile. Worse,
even when removing the acquire/release_output_mutex bracket, there's an
just as high probablity that the master will hang in the WriteFile call.
If the master process is not handling reading and writing from the pipe
in different threads, but just using a single-threaded select loop, the
fate of both processes is sealed.
The obvious culprit here is that the master side echos into the same
pipe write side the slave is writing to. It occured to me that the
problem should disappear if we decouple echo output from slave output.
So the idea was that doecho should write into its own echo pipe and
fhandler_pty_master::process_slave_output as well as select's peek_pipe
both check for data in the echo pipe.
The result is the patch I attached to this mail. I'm not sure it's the
most feasible way to solve this problem, but it works pretty nicely for
me, including pasting big chunks (I tried a clipboard with about 70K
of data) while yes(1) is running.
As a side effect, we can get rid of the acquire/release_output_mutex
bracketing which should speed up output slightly (but reading on the
master side is slightly slower now...)
Please have a look.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
Index: fhandler.h
===
RCS file: /cvs/src/src/winsup/cygwin/fhandler.h,v
retrieving revision 1.513
diff -u -p -r1.513 fhandler.h
--- fhandler.h 24 Feb 2015 11:05:02 - 1.513
+++ fhandler.h 4 Mar 2015 18:11:38 -
@@ -414,6 +414,7 @@ public:
virtual HANDLE get_io_handle () { return io_handle; }
virtual HANDLE get_output_handle () { return io_handle; }
virtual HANDLE get_stat_handle () { return pc.handle () ?: io_handle; }
+ virtual HANDLE get_echo_handle () const { return NULL; }
virtual bool hit_eof () {return false;}
virtual select_record *select_read (select_stuff *);
virtual select_record *select_write (select_stuff *);
@@ -1569,11 +1570,13 @@ class fhandler_pty_master: public fhandl
HANDLE master_ctl; // Control socket for handle duplication
cygthread *master_thread;// Master control thread
HANDLE from_master, to_master;
+ HANDLE echo_r, echo_w;
DWORD dwProcessId; // Owner of master handles
public:
int need_nl; // Next read should start with \n
+ HANDLE get_echo_handle () const { return echo_r; }
/* Constructor */
fhandler_pty_master (int);
Index: fhandler_tty.cc
===
RCS file: /cvs/src/src/winsup/cygwin/fhandler_tty.cc,v
retrieving revision 1.290
diff -u -p -r1.290 fhandler_tty.cc
--- fhandler_tty.cc 25 Feb 2015 16:46:57 - 1.290
+++ fhandler_tty.cc 4 Mar 2015 18:11:38 -
@@ -145,10 +145,8 @@ fhandler_pty_common::__release_output_mu
void
fhandler_pty_master::doecho (const void *str, DWORD len)
{
- acquire_output_mutex (INFINITE);
- if (!WriteFile (to_master, str, len, len, NULL))
-termios_printf (Write to %p failed, %E, to_master);
- release_output_mutex ();
+ if (!WriteFile (echo_w, str, len, len, NULL))
+termios_printf (Write to echo pipe failed, %E);
}
int
@@ -221,6 +219,7 @@ fhandler_pty_master::process_slave_outpu
size_t rlen;
char outbuf[OUT_BUFFER_SIZE + 1];
DWORD n;
+ DWORD echo_cnt;
int column = 0;
int rc = 0;
@@ -257,9 +256,12 @@ fhandler_pty_master::process_slave_outpu
if (rlen sizeof outbuf)
rlen = sizeof outbuf;
- n = 0;
+ n = echo_cnt = 0;
for (;;)
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
On Mar 4 20:34, Takashi Yano wrote: On Mon, 2 Mar 2015 15:44:26 +0100 Corinna Vinschen corinna-cyg...@cygwin.com wrote: 1) Buffer of named pipe gets full-filled by a lot of data written by slave side. 2) WriteFile() in fhandler_pty_master::doecho(), which is called from master side by key input, is blocked because the buffer is full. 3) If a handling to read from the pipe is in the same thread as key input, the thread falls into deadlock. To check buffer space before WriteFile() is one idea, but it is not smart, I suppose... I think that's not it. For testing I added code to convert the WriteFile calls in fhandler_pty_slave::write, fhandler_pty_master::doecho and fhandler_pty_slave::write to overlapped I/O and made sure to wait for the result after the output mutex has been released. This change has no effect at all. Looks like this needs some more digging. Hmm. To confirm my assumption, I have modified the TTY code for testing. The modification is shown in an attached diff-file against current CVS version. (Note that this patch is not for fixing the problem. It is for just a testing.) With this modification, half of buffer is kept empty for fhandler_pty_master::doecho(). I assumed the blocking could be avoided because buffer is always free. As a result of the test, it has become clear that this modification conceals the problem. This means the problem is closely related to occupancy of buffer. Now, I suppose the cause has been clarified. So we have to work out a solution. How can we resolve this problem? I'm not sure. I still have to look deeper into that. Locally I treid to woraround this problem by calling WriteFile overlapped without waiting for the result, but even that doesn't work. Hmm, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpRfCJlgRI8a.pgp Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
On Mon, 2 Mar 2015 15:44:26 +0100 Corinna Vinschen corinna-cyg...@cygwin.com wrote: 1) Buffer of named pipe gets full-filled by a lot of data written by slave side. 2) WriteFile() in fhandler_pty_master::doecho(), which is called from master side by key input, is blocked because the buffer is full. 3) If a handling to read from the pipe is in the same thread as key input, the thread falls into deadlock. To check buffer space before WriteFile() is one idea, but it is not smart, I suppose... I think that's not it. For testing I added code to convert the WriteFile calls in fhandler_pty_slave::write, fhandler_pty_master::doecho and fhandler_pty_slave::write to overlapped I/O and made sure to wait for the result after the output mutex has been released. This change has no effect at all. Looks like this needs some more digging. Hmm. To confirm my assumption, I have modified the TTY code for testing. The modification is shown in an attached diff-file against current CVS version. (Note that this patch is not for fixing the problem. It is for just a testing.) With this modification, half of buffer is kept empty for fhandler_pty_master::doecho(). I assumed the blocking could be avoided because buffer is always free. As a result of the test, it has become clear that this modification conceals the problem. This means the problem is closely related to occupancy of buffer. Now, I suppose the cause has been clarified. So we have to work out a solution. How can we resolve this problem? -- Takashi Yano takashi.y...@nifty.ne.jp cygwin-test.patch.20150304 Description: Binary data -- 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
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
On Mar 2 15:44, Corinna Vinschen wrote: Hi Takashi, On Mar 2 20:45, Takashi Yano wrote: On Sat, 28 Feb 2015 15:02:51 +0100 Corinna Vinschen corinna-cyg...@cygwin.com wrote: Hmm, I can reproduce this even with stty -echo. The tty code is not Some shells seem to re-enable echo when it goes back into prompt. Please put both 'stty' and 'yes' in one command line, separating them with semi-colon. Uh, ok, I didn't realize that. exactly my domain, so I'm not sure at the moment where to look. I guess the locking strategy in the tty code is not robust enough. Did you have a look into the cygwin sources in the meantime, by any chance? To tell the truth, I have looked into the source code. I guess the mechanism of blocking is as follows. 1) Buffer of named pipe gets full-filled by a lot of data written by slave side. 2) WriteFile() in fhandler_pty_master::doecho(), which is called from master side by key input, is blocked because the buffer is full. 3) If a handling to read from the pipe is in the same thread as key input, the thread falls into deadlock. To check buffer space before WriteFile() is one idea, but it is not smart, I suppose... I think that's not it. For testing I added code to convert the WriteFile calls in fhandler_pty_slave::write, fhandler_pty_master::doecho and fhandler_pty_slave::write to overlapped I/O and made sure to wait Copy/paste didn't quite work as I expected. Substitute one of these fhandler_pty_slave::write with fhandler_pty_master::accept_input. for the result after the output mutex has been released. This change has no effect at all. Looks like this needs some more digging. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp0s81slMagx.pgp Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Takashi, On Mar 2 20:45, Takashi Yano wrote: On Sat, 28 Feb 2015 15:02:51 +0100 Corinna Vinschen corinna-cyg...@cygwin.com wrote: Hmm, I can reproduce this even with stty -echo. The tty code is not Some shells seem to re-enable echo when it goes back into prompt. Please put both 'stty' and 'yes' in one command line, separating them with semi-colon. Uh, ok, I didn't realize that. exactly my domain, so I'm not sure at the moment where to look. I guess the locking strategy in the tty code is not robust enough. Did you have a look into the cygwin sources in the meantime, by any chance? To tell the truth, I have looked into the source code. I guess the mechanism of blocking is as follows. 1) Buffer of named pipe gets full-filled by a lot of data written by slave side. 2) WriteFile() in fhandler_pty_master::doecho(), which is called from master side by key input, is blocked because the buffer is full. 3) If a handling to read from the pipe is in the same thread as key input, the thread falls into deadlock. To check buffer space before WriteFile() is one idea, but it is not smart, I suppose... I think that's not it. For testing I added code to convert the WriteFile calls in fhandler_pty_slave::write, fhandler_pty_master::doecho and fhandler_pty_slave::write to overlapped I/O and made sure to wait for the result after the output mutex has been released. This change has no effect at all. Looks like this needs some more digging. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpauKsvbubVC.pgp Description: PGP signature
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
On Sat, 28 Feb 2015 15:02:51 +0100 Corinna Vinschen corinna-cyg...@cygwin.com wrote: Hmm, I can reproduce this even with stty -echo. The tty code is not Some shells seem to re-enable echo when it goes back into prompt. Please put both 'stty' and 'yes' in one command line, separating them with semi-colon. exactly my domain, so I'm not sure at the moment where to look. I guess the locking strategy in the tty code is not robust enough. Did you have a look into the cygwin sources in the meantime, by any chance? To tell the truth, I have looked into the source code. I guess the mechanism of blocking is as follows. 1) Buffer of named pipe gets full-filled by a lot of data written by slave side. 2) WriteFile() in fhandler_pty_master::doecho(), which is called from master side by key input, is blocked because the buffer is full. 3) If a handling to read from the pipe is in the same thread as key input, the thread falls into deadlock. To check buffer space before WriteFile() is one idea, but it is not smart, I suppose... -- Takashi Yano takashi.y...@nifty.ne.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
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
On 2015-02-28 06:40, Takashi Yano wrote: Package: cygwin Version: 1.7.34-6 Cygwin often hangs up if several keys are input during a lot of text outputs. To reproduce this problem: 1) Start a new cygwin session on mintty. 2) Execute yes or od /dev/urandom 3) Hit 'a' key several times during text outputs. If echo is disabled like: stty -echo; yes the problem does not occur. I concur. The same occurs under xterm and 1.7.35-0.5 (under NT). You can pipe your yes/od command into 'head -1' and the same applies (as long as you type the additional characters before the end of course). In fact, Cygwin does not hang, only the xterm window hangs. And, the same: with 'stty -echo' the problem does not occur. I'll add that this is not new (occurred for me at least for the last few months, even perhaps years). I'm happy that Takashi found: - a fully reproducible case - that the problem vanishes with stty -echo (that could perhaps mean a quick resolution...) Regards, Denis Excoffier. -- 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
Re: Cygwin hangs up if several keys are typed during outputting a lot of texts.
Hi Takashi, On Feb 28 14:40, Takashi Yano wrote: Package: cygwin Version: 1.7.34-6 Cygwin often hangs up if several keys are input during a lot of text outputs. To reproduce this problem: 1) Start a new cygwin session on mintty. 2) Execute yes or od /dev/urandom 3) Hit 'a' key several times during text outputs. If echo is disabled like: stty -echo; yes the problem does not occur. Hmm, I can reproduce this even with stty -echo. The tty code is not exactly my domain, so I'm not sure at the moment where to look. I guess the locking strategy in the tty code is not robust enough. Did you have a look into the cygwin sources in the meantime, by any chance? Since this is not a regression from 1.7.34, I'll defer this problem until after the 1.7.35 release. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpHh62bXS48o.pgp Description: PGP signature
