On Tue, 8 May 2007, chas williams - CONTRACTOR wrote:
In message <[EMAIL PROTECTED]>,Jeffrey Hutzelman w
rites:
The problem with this is that it requires every caller to know whether the
thing it is allocating is "huge" or "not huge", where the distinction
depends on the operating system, platform, and perhaps even kernel
configuration. That means we'd be pushing platform-dependent code into
every caller of osi_Alloc, which is exactly what the abstraction is
intended to prevent.
yet there is precedent for this already: osi_Alloc{Small,Medium,Large}Space.
i am only asking for 33% more insanity. perhaps the distinction of huge
and not huge is not appropriate; pageable versus non-pageable might be
a better choice.
currently, you have no clear idea (you can guess) what kind of memory you
might be from the allocator. this does have an effect on reproducibility
of certain bugs.
allocate an extra amount of memory for each allocation, making it aligned,
and put a tag saying how to free it in each allocation, then the
alloc/free package and not the caller can decide how to allocate.
it would also serve to point out sections of the afs code
that could stand some improvement.
No; the size of individual memory allocations is not necessarily an
indicator of code quality.
i should have said 'could possibly'. however, you must admit the
larger the allocation the more likely it is to fail. afs doesnt
typically handle allocation failures well.
you're just saying that because you don't like panics.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
