Greetings! "Mike Thomas" <[EMAIL PROTECTED]> writes:
> Hi Camm. > > | Greetings! Its just come to my attention that GCL may face some > | artificially stiff memory requirements at compilation time due to our > | calling gcc via fork(). > > Is this because system() is implemented with fork()/exec()? > > | I had thought that on most Linux-like > | systems, fork() used copy on write pages, and required no immediate > | extra memory. I may be mistaken, and fork() may fail if there is not > | at least twice the current *virtual* memory available on the system. > | If so, we should redesign and call gcc via run-process. > > Either way, GCL run-process uses fork()/exec() on Unix so I imagine you'll > wind up in the same boat. > Well, that was a rather clueless oversight on my part. My apologies. As I stated in my earlier post, I'm not sure this is a problem. On the alpha machine I used to test the native alpha relocations, fork() was failing when the virtual image size was roughly half the available memory. The man page states that only memory for the parent's *page tables* are required, as would make sense with a copy on write strategy, so perhaps something else was going on. I guess I was asking if anyone else had ever seen a spawned gcc fail with -1 return from system due to memory constraints. In the absence of threads, I suppose the only way around this is with a separate server program like gcltksrv. Needless to say, unless we're sure this is a problem, we won't be going down this route. Take care, > Cheers > > Mike Thomas. > > > > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
