You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by jean-frederic clere <jf...@gmail.com> on 2009/05/13 21:22:07 UTC

Re: svn commit: r774454 - in /httpd/httpd/trunk: include/ap_slotmem.h modules/mem/mod_plainmem.c modules/mem/mod_sharedmem.c server/slotmem.c

jim@apache.org wrote:
> Author: jim
> Date: Wed May 13 18:04:05 2009
> New Revision: 774454
> 
> URL: http://svn.apache.org/viewvc?rev=774454&view=rev
> Log:
> ap_slotmem_mem no longer exists. We never provide the ptr to
> the actual mem. Instead, we rely solely on getter/setter

Why? I am using it :-(

Cheers

Jean-Frederic

Re: svn commit: r774454 - in /httpd/httpd/trunk: include/ap_slotmem.h modules/mem/mod_plainmem.c modules/mem/mod_sharedmem.c server/slotmem.c

Posted by jean-frederic clere <jf...@gmail.com>.
Jim Jagielski wrote:
> 
> On May 14, 2009, at 10:16 AM, Jim Jagielski wrote:
> 
>>
>> On May 14, 2009, at 2:33 AM, jean-frederic clere wrote:
>>> Thanks.
>>> The idea of ap_slotmem_mem is to provide an address in the shared 
>>> area that can be used for example like the proxy_worker_stat. Using 
>>> get/put would require 2 memcpy.... I hate memcpy :)
>>>
>>
>> This is true... Updating would require a memcpy to read in and a memcpy
>> to update, whereas having a pointer means we can adjust the slot
>> as is (at most, one memcpy). Most slots would need to return APR_ENOTIMPL
>> because a concept of a "pointer to a slot" doesn't make sense.
>>
> 
> Hmmmm maybe instead of slotmem_mem we call it slotmem_dptr (for 
> direct-pointer),
> to make it clearer?? SQL-based slots, for example, would not have a
> dptr and would return APR_ENOTIMPL.
> 

+1. Good names help :-)

Cheers

Jean-Frederic

Re: svn commit: r774454 - in /httpd/httpd/trunk: include/ap_slotmem.h modules/mem/mod_plainmem.c modules/mem/mod_sharedmem.c server/slotmem.c

Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 14, 2009, at 10:16 AM, Jim Jagielski wrote:

>
> On May 14, 2009, at 2:33 AM, jean-frederic clere wrote:
>> Thanks.
>> The idea of ap_slotmem_mem is to provide an address in the shared  
>> area that can be used for example like the proxy_worker_stat. Using  
>> get/put would require 2 memcpy.... I hate memcpy :)
>>
>
> This is true... Updating would require a memcpy to read in and a  
> memcpy
> to update, whereas having a pointer means we can adjust the slot
> as is (at most, one memcpy). Most slots would need to return  
> APR_ENOTIMPL
> because a concept of a "pointer to a slot" doesn't make sense.
>

Hmmmm maybe instead of slotmem_mem we call it slotmem_dptr (for direct- 
pointer),
to make it clearer?? SQL-based slots, for example, would not have a
dptr and would return APR_ENOTIMPL.

Re: svn commit: r774454 - in /httpd/httpd/trunk: include/ap_slotmem.h modules/mem/mod_plainmem.c modules/mem/mod_sharedmem.c server/slotmem.c

Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 14, 2009, at 2:33 AM, jean-frederic clere wrote:

> Jim Jagielski wrote:
>> On May 13, 2009, at 3:40 PM, Jim Jagielski wrote:
>>>
>>> On May 13, 2009, at 3:22 PM, jean-frederic clere wrote:
>>>
>>>> jim@apache.org wrote:
>>>>> Author: jim
>>>>> Date: Wed May 13 18:04:05 2009
>>>>> New Revision: 774454
>>>>> URL: http://svn.apache.org/viewvc?rev=774454&view=rev
>>>>> Log:
>>>>> ap_slotmem_mem no longer exists. We never provide the ptr to
>>>>> the actual mem. Instead, we rely solely on getter/setter
>>>>
>>>> Why? I am using it :-(
>>>>
>>>
>>> Oops! Sorry. We can add it back in... But what does
>>> ap_slotmem_mem provide that ap_slotmem_get/ap_slotmem_put?
>>> Again, the idea is that we abstract out the memory handling.
>>> So why do you need the memory pointer if you have a getter and
>>> setter which handles accessing... But no prob putting it back.
>>>
>> patch reverted
>
> Thanks.
> The idea of ap_slotmem_mem is to provide an address in the shared  
> area that can be used for example like the proxy_worker_stat. Using  
> get/put would require 2 memcpy.... I hate memcpy :)
>

This is true... Updating would require a memcpy to read in and a memcpy
to update, whereas having a pointer means we can adjust the slot
as is (at most, one memcpy). Most slots would need to return  
APR_ENOTIMPL
because a concept of a "pointer to a slot" doesn't make sense.

Re: svn commit: r774454 - in /httpd/httpd/trunk: include/ap_slotmem.h modules/mem/mod_plainmem.c modules/mem/mod_sharedmem.c server/slotmem.c

Posted by jean-frederic clere <jf...@gmail.com>.
Jim Jagielski wrote:
> 
> On May 13, 2009, at 3:40 PM, Jim Jagielski wrote:
> 
>>
>> On May 13, 2009, at 3:22 PM, jean-frederic clere wrote:
>>
>>> jim@apache.org wrote:
>>>> Author: jim
>>>> Date: Wed May 13 18:04:05 2009
>>>> New Revision: 774454
>>>> URL: http://svn.apache.org/viewvc?rev=774454&view=rev
>>>> Log:
>>>> ap_slotmem_mem no longer exists. We never provide the ptr to
>>>> the actual mem. Instead, we rely solely on getter/setter
>>>
>>> Why? I am using it :-(
>>>
>>
>> Oops! Sorry. We can add it back in... But what does
>> ap_slotmem_mem provide that ap_slotmem_get/ap_slotmem_put?
>> Again, the idea is that we abstract out the memory handling.
>> So why do you need the memory pointer if you have a getter and
>> setter which handles accessing... But no prob putting it back.
>>
> 
> patch reverted

Thanks.
The idea of ap_slotmem_mem is to provide an address in the shared area 
that can be used for example like the proxy_worker_stat. Using get/put 
would require 2 memcpy.... I hate memcpy :)

Cheers

Jean-Frederic

> 


Re: svn commit: r774454 - in /httpd/httpd/trunk: include/ap_slotmem.h modules/mem/mod_plainmem.c modules/mem/mod_sharedmem.c server/slotmem.c

Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 13, 2009, at 3:40 PM, Jim Jagielski wrote:

>
> On May 13, 2009, at 3:22 PM, jean-frederic clere wrote:
>
>> jim@apache.org wrote:
>>> Author: jim
>>> Date: Wed May 13 18:04:05 2009
>>> New Revision: 774454
>>> URL: http://svn.apache.org/viewvc?rev=774454&view=rev
>>> Log:
>>> ap_slotmem_mem no longer exists. We never provide the ptr to
>>> the actual mem. Instead, we rely solely on getter/setter
>>
>> Why? I am using it :-(
>>
>
> Oops! Sorry. We can add it back in... But what does
> ap_slotmem_mem provide that ap_slotmem_get/ap_slotmem_put?
> Again, the idea is that we abstract out the memory handling.
> So why do you need the memory pointer if you have a getter and
> setter which handles accessing... But no prob putting it back.
>

patch reverted

Re: svn commit: r774454 - in /httpd/httpd/trunk: include/ap_slotmem.h modules/mem/mod_plainmem.c modules/mem/mod_sharedmem.c server/slotmem.c

Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 13, 2009, at 3:22 PM, jean-frederic clere wrote:

> jim@apache.org wrote:
>> Author: jim
>> Date: Wed May 13 18:04:05 2009
>> New Revision: 774454
>> URL: http://svn.apache.org/viewvc?rev=774454&view=rev
>> Log:
>> ap_slotmem_mem no longer exists. We never provide the ptr to
>> the actual mem. Instead, we rely solely on getter/setter
>
> Why? I am using it :-(
>

Oops! Sorry. We can add it back in... But what does
ap_slotmem_mem provide that ap_slotmem_get/ap_slotmem_put?
Again, the idea is that we abstract out the memory handling.
So why do you need the memory pointer if you have a getter and
setter which handles accessing... But no prob putting it back.