Re: hackerlab fsplay.[ch] status

Tom Lord <lord-1tv/[email protected]> writes:

>     > I thought we'd want to save that for object data areas, since
>     > hashq values might be used *very* often (additionally, with
>     > lim_malloc(), when using limits, the overhead increases by
>     > another 4 bytes).
>
> lim_malloc doesn't increase overhead by another 4 bytes if you're
> using it the way it's usually used -- as a front-end to ordinary
> malloc.
>
That's why I said: when using limits. 

> --------------------------------
>
> I wish I had some conclusive, obviously true statement to wrap up
> with.  I don't.  If by next year I've completely embraced a mem_chunk
> interface in hackerlab you're officially not allowed to call me a
> hypocrite.   Until then....
>
Since you seem quite opposed to the memchunk idea, I took another look
at the object data areas, and it seems instead of having the data in a
separate memchunk, we might as well keep it in the hashtree items,
thus avoiding the memchunk issue.


Andy
-- 
Andreas Rottmann         | [email protected]      | [email protected] | [email protected]
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

It's *GNU*/Linux dammit!