On 1/30/05 12:04 PM, David Duncan didst favor us with:
> On Jan 30, 2005, at 10:16 AM, Mike Kluev wrote:
>
>> Or carefully track memory usage and compare it to remaining space.
>> In other words, malloc should "reserve" vm space and this reservation
>> should be honored by other mallocs or file operations (!) and that
>> should be system wide. If that is true, then in the above example
>> NewHandle(.9GB) will fail and NewHandle(.4GB) will succeed.
>
> And of course, there are disadvantages to that as well. What if .9GB is
> allocated and only .4GB of it is used (for whatever reason). And what
> if .4GB was available on disk when the handle was requested but .9GB
> becomes free later (who knows why). And of course, the ever popular App
> A requests .4GB that it will use over the course of an hour, while App
> B needs 1MB that it will need right now but will be done with in 30
> seconds. Why should App B be starved because App A preallocated?
>
> In the end, there is no perfect VM allocation strategy, they all have
> some horrible edge case where the system has to throw up it's hands and
> request user action to resolve the issue. Of course, the user can just
> decide to get the biggest HD available and make the problem mostly
> transparent if it bothers them that often. Again, an imperfect solution
> to an imperfect world :).
The solutions here are nothing remarkable:
- Lots of RAM.
- Have plenty of available hard disk space.
- User memory as sparingly as you can.
If you anticipate straining the 4GB limit on a regular basis, you should
document what users can do to minimize the problems.
Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
