This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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-cygwin@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
Attachment:
x.diff
Description: Text document
Attachment:
pgpOEI93ZMO4V.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |