httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: 2_0_28 tarballs rolled and available
Date Thu, 15 Nov 2001 16:34:18 GMT
On Tue, Nov 13, 2001 at 12:27:48AM -0800, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> -----Original Message-----
> From: Aaron Bannert [mailto:aaron@clove.org]
> >I think Justin is going in the other direction -- your proposed changes
> >need to be broken down into finer grained proposals/functionality.
> 
> I don't think I quite got it - I'll probably wait and see what he means by
> "a new APR API for accessing shmem that treats it as a fixed-length
> hash/DBM".. I'd be willing to help if required.

Sorry for not replying sooner.  I hurt my shoulder yesterday, so I
can barely raise my head - let alone use a computer.  It's a little
better - enough that I can type this out, but not much more.  So,
any code from me will have to wait until my shoulder gets better
(weekend?).

Anyway, the problem that I have in your patch was that we introduce
dynamic memory allocation on top of the shmem.  It is an immensely
complicated piece of code, so I'd like to see if we can avoid having
to add it just for mod_ssl.

So, my idea in short:
- Allocate a shmem DBM - giving it the number of elements you want
  to store and the max size of each element you want to store.
  This will return some dbm (we *may* be able to integrate it with
  gstein's recent work on factoring out DBM code) that APR allocated
  from shmem.  You would do this in the parent before fork()ing off,
  so all children have access to this shmem region.
  
- We must keep it fixed length in both key length and in data
  size.  It must only store a char* (essentially a counted void*)
  because shmem doesn't allow pointers in its data sets.  This
  *should* be sufficient for mod_ssl?  All you want to do is keep 
  the session private key (or similar), right?  It is a static
  buffer with a fixed size.

Rough functions (ignore the names):
- apr_shmem_dbm_create(size_t maxelems, size_t maxklen, size_t maxvlen)
- apr_shmem_dbm_put(char* key, size_t klen, char *val, size_t vlen)
- apr_shmem_dbm_get(char* key, size_t klen, char **val, size_t *vlen)
- apr_shmem_dbm_iterate()
- apr_shmem_dbm_next()
- blah, blah, blah

> I do share your concerns regarding the overhead.. But, I still feel that
> freelist management should be a part of any shared memory management. If
> there's no such policy, then we should just not coin the word *management* -
> because there's no management being done here.

shmem == shared memory.  We never said shared memory management.  =)

How does this sound?  -- justin


Mime
View raw message