Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <42E95BA9.4050103@tlinx.org> Date: Thu, 28 Jul 2005 15:26:49 -0700 From: Linda W User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: cygwin AT cygwin DOT com CC: Alex Goldman Subject: Regression: (was Re: Ctrl-C not working as well as on Linux) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/