apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <madhusudan_mathiha...@hp.com>
Subject RE: [PROPOSAL] apr_shm_t, a new shared memory API to replace old
Date Tue, 08 Jan 2002 00:49:38 GMT

But, as regards SSL session caching, the cache initialization is done only
in the 2nd phase, and all the children are supposed to inherit the
segment-id from that point onwards.. (somebody, pl. correct me if i'm wrong)


-----Original Message-----
From: William A. Rowe, Jr. [mailto:wrowe@covalent.net]
Sent: Monday, January 07, 2002 4:33 PM
To: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1); 'Aaron Bannert';
Subject: Re: [PROPOSAL] apr_shm_t, a new shared memory API to replace

From: "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)"
Sent: Monday, January 07, 2002 6:14 PM

> Wow !!. This is good.. Does this mean that we'll have a *full*
> implementation of the SHMEM atleast now ??.. I'm eagarly waiting for it
> :-).. 

A full implementation of only shm ... if you want 'memory management', you 
pass the base pointer and size to rmm :)

I noted one thing that perhaps was forgotten.  We have two forms of
one that you pass the key into, and the second (better called reattach())
you will pass the apr_shm_t into, obtained from the parent, that the child
must call after fork to have a true shm segment once again.  If it wasn't
called, I believe the child gets a private copy of the shm (which is no

Unless I'm missing something obvious...

View raw message