This is the mail archive of the cygwin@sourceware.cygnus.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: pinfo_mutex?




On Sun, 22 Jun 1997, Roger Kuhlman wrote:
> There are two issues.
> 
> 1) if you are using NT, or Win95 you are not going to get much joy with less
> than 64mb real memory, and about another 64mb of swap when compiling
> with recursive makes or recursive autoconfiguration schemes.
> You also have to watch out with recursive operations that open files
> and then spawn processes. I have occasionally had cross linking of
> files when a spawn failed.

I run NT Server on a Pentium with 32mb ram and about 40 swap spread out on
two drives and it runs fairly quickly. I've run 95 too on the same
machine, and things do run faster (cause 95 uses less ram) even with 32 mb
swap. Running 95 on a 486 with 20mb ram & 20mb swap, things were painfully
slow, but that was most probably due to the fact I was using a 486, no
major disk swapping.
 
> 2) During recursive makes(makes that call make, the preproccessor, etc).
> I have on three occasions had a general protection fault that brought about
> an OS crash with a diagnostic screen--the equivalent of a Unix panic.
> The filesystem came up dirty under those conditions, and I lost the 
> files that were still in buffers when that happened.

I've only seen a "blue screen" once on NT, and that was when someone ran
WinNuke on me (nt dumping core.. what fun..), gnu-win32 has never brought
down my system.  Using alt-ctrl-del to close programs on Win95 has brought
major unstability to my system and sometimes rebooted the system, but make
itself hasn't done that to me.
 
> 	This is not really the fault of the gnuwin32 stuff.  This will
> not occur on any Unix, even if the version of gnumake does not check 
> load before doing a recursion(some of the older versions of gnumake did
> produce process table full exceptions resulting in the orderly death of the  
> calling process i.e. an exit from the loader).
> 
> 	For your own sanity, use a -j 1 argument to make, and make sure
> $MAKEFLAG is -j 1 in recursive calls. This assures that make will not
> spawn unimpeded.
*shrug*
> 	Perhaps Microsoft can address the issue in Memphis and NT5.

LOL, Microsoft fixing bugs... man that's a good way to get a laugh.

- alex

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


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