Regression: (was Re: Ctrl-C not working as well as on Linux)

[Linda W]

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/