X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,TW_DB,TW_RX,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org X-Yahoo-SMTP: jenXL62swBAWhMTL3wnej93oaS0ClBQOAKs8jbEbx_o- Date: Thu, 19 May 2011 15:11:11 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Re: High Activity of setprogname Message-ID: <20110519191111.GB15673@ednor.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <4DD5565B DOT 1070607 AT ece DOT cmu DOT edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD5565B.1070607@ece.cmu.edu> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: 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 On Thu, May 19, 2011 at 01:41:47PM -0400, Ryan Johnson wrote: >On 2:59 PM, Sravan Bhamidipati wrote: >> Terminals like mintty and rxvt are doing an unusual amount of context >> switching and consuming a lot of CPU cycles even in idle time. Process >> Explorer suggests that this activity is largely attributable to >> "cygwin1.dll!setprogname". Could this be something that should not or >> need not be done? (Running cygwin.bat directly to use Cygwin doesn't >> show such activity.) >> >> Most recently I've been seeing this behavior with Mintty v0.97, Cygwin >> v1.7.9-1, Windows 7 Ultimate SP1 (x64, Build Version: 6.1.7601 Service >> Pack 1 Build 7601). However I've noticed this in a few older versions >> of Mintty, Cygwin as well, even on Windows XP. >> >> You can also view the mintty thread where this discussion began: >> http://code.google.com/p/mintty/issues/detail?id=265 >The running code is related to select() (try running strace -mselect >mintty to see for yourself). > >A little poking around with windbg and gdb shows that select.cc:650 >(thread_pipe) is the culprit: select itself is called with infinite >timeout; somebody more knowledgeable than me will have to explain why >thread_pipe would return data so often for an idle process, however. It's called "polling", see: http://msdn.microsoft.com/en-us/library/aa365779%28v=vs.85%29.aspx cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple