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 Date: Mon, 14 Jun 2004 13:56:40 -0500 From: Brian Ford Reply-To: cygwin AT cygwin DOT com To: cygwin AT cygwin DOT com cc: fergus AT bonhard DOT uklinux DOT net Subject: Re: FW: wish84 incredibly slow In-Reply-To: Message-ID: References: <200406130626 DOT i5D6QrgN013801 AT mailgw01 DOT flightsafety DOT com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes On Mon, 14 Jun 2004, Brian Ford wrote: > On Sun, 13 Jun 2004, fergus wrote: > > but on every occasion that I tried this experiment, the longest individual > > call, dwarfing all others, is a call towards the end (actually 17th from > > last in all the examples of wish.log that I tried) beginning > > > > [unknown ... > > > > In one instance this call took more than 100 times longer than the next > > longest call, but usually the factor was order 10-30. > > Could you send me the output of "fgrep unknown wish.log". If the list > won't accept it, privately is fine. I don't promise to find anything, but > I'm at least mildly interested. Um..., nevermind. That would probably not be useful. All that time elapses between these two calls: 876 6251810 [main] wish84 3360 path_conv::check: this->path(g:\home\user\wishrc.tcl), has_acls(0) 35680785 41932595 [unknown (0xA64)] wish84 3360 _cygtls::remove: wait 0xFFFFFFFF and since the debug print for the unknown thread is at the beginning of the _cygtls::remove function, that is not the problem. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- 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/