Re^2: control-C to "jumpstart" windows process

[jimt]

I was very hopeful about this, but it doesn't appear to be the case. I'm basing this off of the fact that when I click on a window, it does indeed freeze the output, but it also appears to freeze the program. I tested this with a simple little loop that just increments a counter. When I enter select mode, the counter freeze. When I exit select mode, the counter resume where it left off.

It appears that our program is continuing to run when we encounter the glitch, it just doesn't display to the screen. So I think it's something different. But this may be the right track.

[tye]

My testing shows "$x++ while 1" continues to consume 100% of the CPU even when I have text in the console window selected. Trying to write output to a frozen window will certainly freeze the program (as your test showed, I assume, based on the fact that you report being able to see the counter increment).

[jimt]

That's a good point - I had my little test program constantly printing out, and that did indeeded freeze. I tweaked it to only print out every 10 passes through the loop, and sure enough that counter did continue to increment properly until it hit the next print, then it froze. So that does imply that it it continues to work and only locks up on output.

Quick edit mode was enabled, which I just shut off. I'll keep my fingers crossed that this was indeed the solution.

[BrowserUk]

If you are printing to STDOUT without having turned off the buffering, then the program will continue producing output and will not be blocked until the buffer has filled.

If the process completes before the buffer fills, then clearing the mark or select state will allow the ouput to finish though the process may have finished some time earlier.

The output will appear contiguous in both cases because of the buffering. No output is discarded, it is simply buffered and displayed once the freeze thaws.

[tye]

Note that output to STDOUT defaults to "line-buffered" mode (except on older versions of Win32 Perl where the default was unbuffered), so this would only apply to a single line of output (based on "\n", not a single row of the terminal window).

[BrowserUk]

Right. I often added debug out using printf "\r%d\t", $loopVariable unless $loopVariable % 1000, but if STDOUT is buffered, then you have to wait for the buffer to fill before you "see" the first output, and then it increments in leaps and bounds. You can see this with:

c:\test>perl -lwe" Win32::Sleep( 10 ),printf qq[\r%d\t], $_ for 1 .. 1
+e6"

Which appears to display (overlaid of course):

841
1550
2232
2915
...

Update: Once you get to 4-digit numbers, the interval is 682. With 4-digits, "\r" & "\t", that is 6 * 682 = 4092. A 4kb buffer.

Whereas if you disable the buffering

c:\test>perl -lwe"$|=1;Win32::Sleep( 10 ),printf qq[\r%d\t], $_ for 1 
+.. 1e6"

You see the number increment from 1, quickly and continuously.

I guess the buffering doesn't consider "\r" as a line ending -- probably rightly. It is useful for monitoring the progress of long running processes. Leaving the buffering enabled means that the IO has a negligable effect upon the speed of the code, and has the beneficial side effect that I can 'pause' and 'resume' the long running process by using the left and right mouse buttons alternately. Mouse equivalent of ^S.