Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

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

by jimt (Chaplain)
on Oct 18, 2006 at 16:06 UTC ( #579124=note: print w/ replies, xml ) Need Help??


in reply to Re: control-C to "jumpstart" windows process
in thread control-C to "jumpstart" windows process

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.


Comment on Re^2: control-C to "jumpstart" windows process
Re^3: control-C to "jumpstart" windows process (frees)
by tye (Cardinal) on Oct 18, 2006 at 16:20 UTC

    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).

    - tye        

      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.

Re^3: control-C to "jumpstart" windows process
by BrowserUk (Pope) on Oct 18, 2006 at 16:21 UTC

    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.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      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).

      - tye        

        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.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://579124]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (7)
As of 2014-09-16 04:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (156 votes), past polls