Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Subject: Re: cygwin slowdown in current cvs version
From: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
To: cygdev <cygwin-developers AT cygwin DOT com>
In-Reply-To: <20010908222326.B937@cygbert.vinschen.de>
References: <130160175780 DOT 20010908204017 AT logos-m DOT ru>
	<127165775081 DOT 20010908221336 AT logos-m DOT ru>
	<186168543292 DOT 20010908225944 AT logos-m DOT ru> <20010908155203 DOT C12571 AT redhat DOT com>
	 <20010908222326 DOT B937 AT cygbert DOT vinschen DOT de>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.13 (Preview Release)
Date: 09 Sep 2001 09:57:56 +1000
Message-Id: <999993477.9501.108.camel@lifelesswks>
Mime-Version: 1.0
X-OriginalArrivalTime: 08 Sep 2001 23:44:48.0773 (UTC) FILETIME=[3F2ACB50:01C138C0]

On Sun, 2001-09-09 at 06:23, Corinna Vinschen wrote:

> I think we should do that.  I'm thinking of a different way to
> do the same by starting an additional thread which wakes up on a
> file change event or something.  AFAICS there's a call in Windows
> which allows that on changes to a directory but not on changes to
> a single file.  Anyway, perhaps that's sufficient for the /etc
> directory.
> 
> What do you think?

I'm for this. I suggested it as a possible improvement some time ago -
ideally via the unix mechanism, and a wrapper for that in cygwin... but
I know _nothing_ about unix change notification (I presume its signal
based) or I'd have dug into that. 

I think putting the UNIX mechanism into cygwin, and using that is good
because that way I expect we can reuse the signal thread to handle this,
rather than creating another thread. As Chris reminded me a day or two
ago, we only get 61 threads per process by default, and every thread
cygwin creates is one less user thread.

> > Have you compared the numbers against 1.3.2 by any chance?
> > 
> > It occurred to me today that by moving the large zombies buffer into the
> > heap, I ended up having fork always copy the array.  I don't know which
> > is better -- having a large dll with a slower load time vs more to copy
> > on fork.
> 
> Hum, I would prefer the larger DLL in that case.  The DLL is loaded
> once,  the fork is pretty often.

The .dll gets reloaded into each new process space every fork anyway.
I'm not sure which will be faster - a memcpy or disk io :]. I suspect
some timing tests would be needed to tell for sure :[.

Rob