I believe this is rather untypical situation, but see below.
How do you figure that? Currently I have 64 processes running. The
smallest virtual size is 17MB and the smallest real size is 28k. And in
fact I have only 4 processes using more than 17MB of real memory (with
Mail & Safari being the only ones I explicitly launched). Every single
GUI app is using at least 100MB of virtual memory.
No malloc, but some other call was called to turn off the memory
protection. This is not my area of expertise, but let's assume
that this call could be designed to be able to fail and return
an error on lack of space (similar to the "pessimistic" malloc).
Same situation.
The problem is that it doesn't necessarily involve a function call
per-se, but can be a side effect of anything. Including calls that
aren't otherwise designed to fail. All it takes is a write to memory in
any of those libraries. It's just one of those things that is
devilishly hard to avoid.
Something has to give, and in most situations only a human can
decide
what is really essential and what isn't.
Looks like the major difference is here: whether to place
responsibility on a user, or on a app.
Alas to put such responsibility on the app would also likely frustrate
the user when these operations that can succeed fail because the system
doesn't want to potentially overcommit. And then the user will have to
quit applications to be able to do the operation the wanted to do.
Which again brings us to what the system already does, except the user
gets said dialog MORE often instead of less often.
By comparison I've seen the "quit apps to free resources" dialog
probably 4 times on Panther and all when I had less than a half gig of
space free on my system partition. Using your method I would have
burned out long ago as the system is reporting that I have over 6GB of
virtual memory mapped, but only 1GB of RAM & 2GB of free disk space.
--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try.
David Duncan
_______________________________________________
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
