httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: ap_slotmem
Date Thu, 14 May 2009 12:31:04 GMT

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 :)

>
>
>>  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().

+1


Mime
View raw message