Mail Archives: cygwin/2005/07/28/18:27:10
Christopher Faylor wrote:
>According to Alex Goldman on 7/21/2005 2:49 AM:
>
>
>>On Linux, after I start a program that consumes 100% of CPU time, I can
>>usually terminate it just by typing Ctrl-C. This is very convenient to
>>me as a developer. However, using Cygwin in the same situation, the
>>shell becomes "bash (Not Responding)", and I have to invoke the process
>>manager and kill the process from there. Does anyone know why this
>>happens and what can be done about it?
>>
>>
>? CTRL-C should work just fine without CYGWIN=tty. In fact, it should
>work better than CYGWIN=tty in situations where system time is being
>consumed by a runaway process.
>
>I don't see any reason why either Cygwin or bash should become unresponsive
>due to a program which consumes CPU.
>
>
-----
A bit belatedly to answer this, I know, but I updated my cygwin.dll
(among others) about a week ago. Since then I've noticed
Control-C doesn't terminate Cygwin programs, promptly, as it used to.
No other settings have changed. I'm running "Bash.exe" natively in
a standard cmd type window. Control-Break yields the same (non) effect.
The problem is greatly noticed wen I do an "ls" on(in) large directories.
My ls, is'ed aliased with "-CGF" by default to default select multiple
columns, suppress "Group" and classify files by appending (*/=@|) to the
entries; as a result, an ls in a large directory can take a while.
It used to be the case that 'ls' would terminate immediately when
I pressed control-C. Now, it finishes reading all the file information
in the directory(a long process), displays the first file, then
recognizes thecontrol-C.
Previously, it would abort the file reading -- now it is not. I
inferred this from the execution time which is a *BIG* indicator.
Note the difference between these two "ls" runs on a 3000+ entry
directory:
/windows/system32> time ls dllcache >/dev/null
real 0m32.794s
user 0m0.580s
sys 0m2.613s
/windows/system32> time ls dllcache >/dev/null
real 0m0.975s
user 0m0.300s
sys 0m0.621s
===================================
After the info is cached, a subsequent ls on the same dir runs
significantly faster (~33x (3300%) faster).
Since the update a week ago, a control-C on an "ls" takes about
30 seconds to respond.
Here's an example with me pressing control-C:
===================================
/windows/options/i386> date;time ls
Thu Jul 28 14:15:21 PDT 2005
12520437.CP_
real 0m56.746s
user 0m1.422s
sys 0m7.550s
/windows/options/i386> date
Thu Jul 28 14:16:18 PDT 2005
===================================
Note it took over 56 seconds to recover after pressing Control-C.
This wasn't the case in prior versions.
Perhaps this is why the original poster suddenly noticed the difference
in control-C processing time?
FYI, my tty settings are as follows:
=====================================
/> tty
/dev/console
/> echo $TTY
/dev/conin
/> echo $CYGWIN
notitle glob:ignorecase export
======================================
I can provide more info if needed.
Linda
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -