[Bf-committers] Some words about a strange thing named
j.merritt at pgrad.unimelb.edu.au
Fri Nov 25 10:54:42 CET 2005
I should add that obviously some atomic operations (say, a mesh
subdivide) could also simply fail (that's another option). Failure in
those cases could be handled by the caller.
(I was thinking about more complicated situations, where recovering from
failure to allocate memory would involve jumping through impossible
hoops to get back to a valid state...)
Jonathan Merritt wrote:
> This is a valid point, but the more important question is:
> "So, we check for NULL, and then do... ? What, exactly?"
> IMHO, a NULL return should typically be handled at a high level by the
> malloc() wrapper. I mean, what can Blender *do* if it can't access
> any more memory? Some suggestions:
> 1. Empty caches, and then try again.
> 2. Give up, try to save and quit (storing a "run out of memory"
> flag in the memory manager to prevent recursion).
> 3. (...)?
> These things should surely be implemented in a high-level memory
> manager, not peppered throughout the code in every function that
> allocates memory. Does anyone disagree?
> Jonathan Merritt.
> Jorrit Tyberghein wrote:
>> Hmm... Exactly how is a system that is returning null for malloc a
>> f*cked up system? On my linux system I have 512Megs RAM and 1Gig swap
>> (not an uncommon setup). Assume that I still have 300Megs free (which
>> is plenty) and then something does a malloc of 300 megs which fails.
>> How is this a f*cked up system? Code should check for failure on
>> memory allocation IMHO. Now in practice I realize that few programs
>> actually do that (Crystal Space doesn't do that either) but returning
>> NULL for malloc is not always indicative of your system being messed
>> up. It can simply be that there is not sufficient memory available for
>> the allocation.
> Bf-committers mailing list
> Bf-committers at projects.blender.org
More information about the Bf-committers