This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]