No cons output/cons uninterruptable during execution
Brought to you by:
bozho
Menu
▾
▴
#366 No cons output/cons uninterruptable during execution
w/latest version 2.00.147, with BOTH, the 32-bit and 64-bit version, there is a major regression that makes it unusable (probably for most people). I am running under Win7-64.
when a command is started, no output is shown until the command finishes. The final output is shown. Console is not interruptable while the program is executing.
Simple example. Using 'bash.exe' from cygwin as a shell, use a loop:
time for ((i=0,lim=5*10**7;i<lim;++i)) {
echo i=$i
}
In 146, you will see the script count up, and pressing control-c at any time will terminate the script.
In 147, you don't see the count up, but only the final page (what you would see if you let the script finish in 146). Worse, you can't interrupt the script's execution -- you must wait until it is done, but ...
>>MUCH WORSE<< -- you can't even close the console window by pressing the 'X' on the window frame -- it won't respond to windows at all. The only way to stop it executing is to kill the process with taskmgr/procexp.
Major regression. This happens in both the 32 and 64 bit version.
FWIW(For what it's worth), I tried altering the values of of "Update Timeouts" for On Change and Periodic from my normal values of 10/100, to values ranging from (1-50),(1-250). No change.
BTW -- What are the exact meanings of these values? My guess was that it should update console output and look for console input if there was a change every "On-change" ms, and in the absence of changes, it will look for input every 'Periodic' ms, but my limited testing didn't seem to reflect this theory, but other factors may have been influencing my limited tests.
Especially during development, but even during normal use, 'commands 'can result in infinite loops or very long periods of execution. That these are uninterruptable is unusable, but that there is no intermediate output makes them completely useless.
Quick fix?
Hm,
I've just tried this script with Console 147 and cygwin bash on Win7 x64... It works just fine: output is printed line by line and the script can be interrupted with CTRL+C.
Can you attach your config file here? Also, can you check the hidden Windows console window? Can you see the output there?
There are two timeouts: 'on change' and 'periodic'
'On change' timeout delays signaling Console's window when there's a change in the hidden Windows console window detected. This prevents flooding Console's window.
'Periodic' update timeout is used for periodic signaling to Console even when there is no change detected, since some console applications allocate a new console screen buffer while they run, and the hook DLL cannot detect changes in the new screen buffer for now. I do have an idea on how to change that...
--
Marko
added console config file
You said to check the "hidden windows console window"...
I've never heard of such a thing. What are you referring to? I don't have a hidden windows console window that I know of. I'm using a non-hidden, open console window and running my 'job'/application in foreground.
Note -- I've never had this problem on any previous version of console (limited to 32bit, as I wasn't able to use 64bit before the newest beta), so I don't know what would be changing with this particular version.
As I mentioned, I experimented by altering the timeout values in the latest to see if that would help, but I didn't find any values that would work -- but I did find that by putting in largish (50/250) on the previous version (the one I'm still using), I can reproduce the
problem, but that's using "abnormal values" (i.e. I wouldn't consider that a bug).
But w/247, I could find any values that *would* work...even 1/1, which should be very responsive to any output, I'd think -- especially given your description of their function.
This is just really weird -- since I'd assume you'd notice the problem in your version/testing because the effects are so annoying, so I am at a loss to explain why it might not be working in my setup.
Let me know how I can help & sorry to find difficult bugs (don't take it personally, it's just my 'luck'... ;-) ).
I think the root cause of this bug is it uses PostMessage to notify the main window of updates in the console, which prevents the main window from ever getting mouse or keyboard messages.
According to MSDN, GetMessage and PeekMessage will process sent, posted, input, sent (again), paint, and finally timer messages, in that order.
If a program produces output fast enough, then it would post a new message before the main window finishes processing the previous message. Since it will always see the posted messages before input messages, it won't see any keyboard or mouse messages until the barrage of posted messages dies down.
I can verify that by modifying the main message loop. I changed the loop so that it would call PeekMessage with the PM_QS_INPUT flag before calling GetMessage. When I did that, I found that it would respond to the keyboard and mouse even during a flood of update messages.
However, modifying the message loop like that doesn't completely solve the problem. When the user clicks on the title bar or the window border, it will enter a recursive message loop to handle moving or resizing the window. The recursive loop doesn't have that special input handling, so it will still lock up.
I don't know if simply throttling the update messages would be enough. Even if you ensure that it will not post a new message until the main window has finished processing the previous one, it could still post the new message before the main window retrieves the next input message. That is, if it posts the message after the main window's update handler returns, but before the next call to GetMessage, then you'll have the same problem.
I think you could use a manual-reset event to signal an update to the console text, and then have the main message loop call MsgWaitForMultipleObjects instead of GetMessage to wait for message to arrive. Then, call PeekMessage to check for any input messages before you process the console update. That way, the main message loop would still process input messages before processing the console update, and any recursive message loops would simply ignore the console update.
impishcoder,
Thanks for a great detective work! I will look into it when I find some time...
I was trying to be clever about painting code and that's never a good thing. Since changes will not be repainted until Console processes paint messages, processing Console updates could probably be delayed until then...
Cheers,
--
Marko
Hm, I've just tested this with bash and the test script provided above with Console 2 b148 and I cannot reproduce it. The output is fine, Console is responsive and I can interrupt the script at any time with CTRL+C.
This is on Win7 x64 and 32-bit Console.