Date: Tue, 30 Aug 94 18:08:46 GMT From: dolan AT fnoc DOT navy DOT mil (Kent Dolan) To: dj AT ctron DOT com Subject: Re: bugs in exec.c et al Cc: djgpp AT sun DOT soe DOT clarkson DOT edu DJ (an androgynous choice of monikers, indeed), Hmmm, BB>>> ..., except that DJ says it isn't supposed to work this way; BB>>> _go32_dpmi_remaining_physical_memory() is supposed to track BB>>> allocations. KPD>> Huh? If the allocation only effectively allocates virtual memory, then KPD>> a function named ...remaining_physical_memory should ignore anything KPD>> that is not yet occupying physical memory. Anything else would disobey KPD>> the principle of least astonishment. DJ> Now *I* am confused. The original intent of this function was to see DJ> how much space one could alloc before swapping happened. What's the DJ> best definition for this after swapping everything out for a spawn? DJ> What *should* it mean? I'd prefer that it mean what it says. If you're calling this during a spawn, then it's the spawned job that is doing the calling, and it wants to know how much physical memory is available to _it_, _right_ _now_. If you're calling this _after_ a spawn, while most of the current task is in virtual memory waiting until it is needed to be swapped back in, then again you the programmer are interested in how much physical memory is available _right_ _now_, because you might have some i/o bound subtask that would run much better in memory, if it and its data would all fit in memory _right_ _now_, and in that case, you don't really much care about the bunch of code sitting swapped out to disk, unless it is going to be involved in the current subtask. My opinions only, I have several decades of programming expreience, but that doesn't make me a universal expert. Nor anything close. Xanthian. -- Kent, the man from xanth. Kent Paul Dolan, CSC contractor at Fleet Numerical. (408) 656-4363. (Navy Unix email: ) (Navy cc:Mail email: ) (real world email: )