You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Cliff Woolley <cl...@yahoo.com> on 2001/05/05 21:35:40 UTC
Re: [WISH] shared memory based apr_pool_t
On Sat, 5 May 2001, Ralf S. Engelschall wrote:
>
> A wish to our APR hackers:
>
> For mod_ssl and certainly also for other purposes we really need shared
> memory based apr_pool_t's, i.e., pools which allocate their memory not
> from the heap but from a shared memory segment. This would allow us to
> complete kick out the large 100KB third-party ssl_util_table.* stuff by
> using just a standard APR hash inside an APR pool which is located in a
> shared memory segment. For EAPI in Apache 1.3 there was a patch against
> alloc.c which provided such a functionality, although mod_ssl was never
> adjusted to use this feature directly.
Sounds like the SMS (stackable memory system) stuff that the Samba-TNG
guys have proposed for APR might be worth some investigation...
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: [WISH] shared memory based apr_pool_t
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Sat, May 05, 2001 at 03:35:40PM -0400, Cliff Woolley wrote:
> On Sat, 5 May 2001, Ralf S. Engelschall wrote:
>
> >
> > A wish to our APR hackers:
> >
> > For mod_ssl and certainly also for other purposes we really need shared
> > memory based apr_pool_t's, i.e., pools which allocate their memory not
> > from the heap but from a shared memory segment. This would allow us to
> > complete kick out the large 100KB third-party ssl_util_table.* stuff by
> > using just a standard APR hash inside an APR pool which is located in a
> > shared memory segment. For EAPI in Apache 1.3 there was a patch against
> > alloc.c which provided such a functionality, although mod_ssl was never
> > adjusted to use this feature directly.
>
> Sounds like the SMS (stackable memory system) stuff that the Samba-TNG
> guys have proposed for APR might be worth some investigation...
just posted about this, on dev@apr.apache.org.
there are unique issues to do with setting up a shared-memory
apr_pool_t.
namely, that the paradigm doesn't work :)
you will need to add an extra function that allows you to enumerate
through all allocated memory blocks, returning to 'you, the user'
all addresses and sizes of all blocks allocated so far within a
specific shared memory block.
in this way, you can have one program ap_pool_alloc() several blocks,
and then have another program or programs obtain the addresses of
those blocks, without interference between the programs.
this is pretty ugly, but to be honest, within the paradigm of the
apr_pool_xxx() API, i don't see another way to do it.
[i am assuming that you know how a shmem-based apr_pool_t, using
apr_memsys, or even if it didn't use apr_memsys, would work.
please let me know, via the dev@apr.apache.org list, once read
my last posting on the subject, if you don't. i have very
bad rsi and only getting worse: typing is therefore at a minimum.
thx.]
luke
Re: [WISH] shared memory based apr_pool_t
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Sat, May 05, 2001 at 03:35:40PM -0400, Cliff Woolley wrote:
> On Sat, 5 May 2001, Ralf S. Engelschall wrote:
>
> >
> > A wish to our APR hackers:
> >
> > For mod_ssl and certainly also for other purposes we really need shared
> > memory based apr_pool_t's, i.e., pools which allocate their memory not
> > from the heap but from a shared memory segment. This would allow us to
> > complete kick out the large 100KB third-party ssl_util_table.* stuff by
> > using just a standard APR hash inside an APR pool which is located in a
> > shared memory segment. For EAPI in Apache 1.3 there was a patch against
> > alloc.c which provided such a functionality, although mod_ssl was never
> > adjusted to use this feature directly.
>
> Sounds like the SMS (stackable memory system) stuff that the Samba-TNG
> guys have proposed for APR might be worth some investigation...
just posted about this, on dev@apr.apache.org.
there are unique issues to do with setting up a shared-memory
apr_pool_t.
namely, that the paradigm doesn't work :)
you will need to add an extra function that allows you to enumerate
through all allocated memory blocks, returning to 'you, the user'
all addresses and sizes of all blocks allocated so far within a
specific shared memory block.
in this way, you can have one program ap_pool_alloc() several blocks,
and then have another program or programs obtain the addresses of
those blocks, without interference between the programs.
this is pretty ugly, but to be honest, within the paradigm of the
apr_pool_xxx() API, i don't see another way to do it.
[i am assuming that you know how a shmem-based apr_pool_t, using
apr_memsys, or even if it didn't use apr_memsys, would work.
please let me know, via the dev@apr.apache.org list, once read
my last posting on the subject, if you don't. i have very
bad rsi and only getting worse: typing is therefore at a minimum.
thx.]
luke