apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: [PROPOSAL] apr_shm_t, a new shared memory API to replace old
Date Tue, 08 Jan 2002 21:39:34 GMT
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.



Mime
View raw message