Mail Archives: cygwin-developers/2001/09/08/19:57:18
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
- Raw text -