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
Correct.. 

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)

-Madhu

-----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';
dev@apr.apache.org
Subject: Re: [PROPOSAL] apr_shm_t, a new shared memory API to replace
old


From: "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)"
<madhusudan_mathihalli@hp.com>
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
attach(),
one that you pass the key into, and the second (better called reattach())
that
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
fun.)

Unless I'm missing something obvious...

Mime
View raw message