Jim Jagielski wrote:
On May 14, 2009, at 2:49 AM, jean-frederic clere wrote:
Jim Jagielski wrote:
On May 13, 2009, at 12:01 PM, jean-frederic clere wrote:
Jim Jagielski wrote:
On May 13, 2009, at 10:17 AM, jean-frederic clere wrote:
Jim Jagielski wrote:
OK, I think having 2 more API functions rounds out the impl;
Consider: the current assumption is that the user manages the
indexes into the slotmem. But what if the user doesn't?
Then he can't use the stuff :-(
Certainly
it would make sense for the slotmem to know what slots are now
currently available and return a "free" slot to the caller.
So I think a "grab" and a "return" function are required as well.
I have malloc() / free() / getused() / getfree() switchable logic
that I can add quickly. Basically it create a table of used and
free slotmem additionally to data it.
*grin*
Yesterday I added in a 'inuse' table,
With a int * instead a char * we could have a kind of next free to
have a fast grab(alloc).
My impl was just a flag table to determine if the slot was used or
not (and hence 1 or 0). If we can overload this for other goodness, then
+1.
I am thinking also 2 other things:
1. We should prevent a get or put if the slot has never
been grabbed (alloc'ed).
I think that should be switchable via a parameter (in the
apslotmem_type).
Additionally I will add a fast alloc logic (just need to change inuse
to an array of int * size +1.
I was thinking about this... where the table contains the actual ids of
the currently used id's. The trouble I see with that is that although
it makes allocs fast, it makes the "is this slot in-use" access slower.
I think we should be fast in the checking (since we may be doing this
much more often, esp if we restrict get/put to only pre-alloced
slots) even if it means being slower in alloc. But maybe you have
a different impl in mind that makes both fast :)
Well you are right grab/return won't occur as often that get/put so
having a fast grab/return and slowing down get/put is a kind of over
engineering.
Cheers
Jean-Frederic
