apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: [PROPOSAL] apr_shm_t, a new shared memory API to replace old
Date Tue, 08 Jan 2002 22:00:51 GMT
On Tuesday 08 January 2002 01:39 pm, William A. Rowe, Jr. wrote:
> From: "Ryan Bloom" <rbb@covalent.net>
> Sent: Tuesday, January 08, 2002 3:04 PM
> 
> 
> > On Tuesday 08 January 2002 12:41 pm, Mladen Turk wrote:
> 
> > > From: "William A. Rowe, Jr." <wrowe@covalent.net>
> > > Sent: Tuesday, January 08, 2002 8:53 PM
> > > 
> > > > I'm also looking at the API and understand why you were worried about
the
> > > > anon.  But what you describe is a hybrid, a named, anon shm.  For now,
we
> > > > will be using backing files; adding both keyed and named create where
the
> > > > platform supports both is a reasonable potential improvement in the
> > > > future.
> > > 
> > > The reason for using a filename and a NAME for that file (that was my
> > > initial post to Aaron) has nothing to do with the keyed/named created shms.
> > > Simply, the Apache could create whatever shmem file with some NAME, and the
> > > rest of the world can access it simply using that NAME.
> 
> Windows names the backing file seperately from an attach()able shared segment.
> Since this is file backed, we will create a 'flat' name (convert the colon and
> slashes to some neutral character and truncate off the left to 255 chars),
> and added to the W2K Terminal Server Global\ namespace.
> 
> So Mladen, we address your concerns.  Someday in the future, we could create
> a 'named' anon (this is called 'keyed' in apr nomenclature) and it's up to
> the processes to agree on an identity.  Since the 'key' is an int, a simple
> name like Local\apr_shm_##### would work.  Again, that's a future improvement :)
> 
> 
> > I'm confused, the NAME is the filename.
> 
> No, to the attach()er, it follows the schema above.

No.  The whole point is that you have to have some way to communicate the
name to the second process. You always use a file, and if you are dealing
with key'ed shared memory, the file just contains the key.  The second process
just reads the file, gets the key, and does the attach.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message