This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: cygwin slowdown in current cvs version


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]