Message-Id: <200406130646.i5D6kCao026487@delorie.com> 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 Reply-To: From: To: Cc: Subject: Re: wish84 incredibly slow Date: Sun, 13 Jun 2004 07:40:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-UoD-Spam-Score: -4.7 (----) X-UoD-Spam-Report: -------------------------------------------------- This message has been scanned by a SpamAssassin installation on the spam checking server hughnew at the University of Dundee. Content analysis details: (-4.7 hits, 5.0 required) 0.2 NO_REAL_NAME From: does not include a real name -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] X-UoD-Scan-Signature: 3424de8397d571007b4f18ae25a2cea4 Note-from-DJ: This may be spam >> [unknown ... Sorry to provide an afterthought, but this might be helpful I hope: Summarising, as looking through any of the logfiles sorted or otherwise is a bit of a bind, I think the explanation of the sloth must lie somewhere in the output of strace /bin/wish84 | grep unknown (a) This output always contains a reference to _cygtls (b) Occasonally, on the very slow Toshiba at least, the output is null (nothing "unknown") corresponding to the cases when wish84 is not so slow to produce the display panel. Fergus -- 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/