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.
2. We should get rid of the ap_slotmem_mem() function...
The user should never need to know the pointer to
the dataset; all access should be via the slot number
and slot name.
It avoids memcpys but in case we have a provider that provides
information distributed in a cluster that would not work. We should add
a note that some slotmem provider may not support ap_slotmem_mem().
Cheers
Jean-Frederic
