Message-Id: <200505162135.j4GLZCXC008360@delorie.com>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: "Gary R. Van Sickle" <g DOT r DOT vansickle AT worldnet DOT att DOT net>
To: <cygwin AT cygwin DOT com>
Subject: RE: Please test latest snapshot
Date: Mon, 16 May 2005 16:38:13 -0500
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To:  <loom.20050516T160024-968@post.gmane.org>
X-IsSubscribed: yes

[snip uberslow network traverse]

> 
> I don't know if there is a reasonable way to speed this up, 
> because you want to ensure that //machine exists before 
> allowing `cd //machine' to succeed, but don't want to go 
> stat'ing every machine on the network when doing a readdir() on //.
> 

I can think of one way: go to a "thread pool" sort of arrangement where you
spawn off a thread to wait for the (non-)responses from network PCs in
parallel.  This would reduce the worst-case traverse time from O(Ttimeout)
to O(Ttimeout/Nsize-of-threapool).

Of course, this would require massive changes to ls, and would unnecessarily
slow down and increase resource usage of the most common use case of ls,
namely getting a simple directory listing of files on a local disk.

-- 
Gary R. Van Sickle


--
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/