----- Original Message -----
From: "Ryan Bloom" <[EMAIL PROTECTED]>
To: "William A. Rowe, Jr." <[EMAIL PROTECTED]>; "Mladen Turk"
<[EMAIL PROTECTED]>; "'Aaron Bannert'" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Tuesday, January 08, 2002 11:00 PM
Subject: Re: [PROPOSAL] apr_shm_t, a new shared memory API to replace old
> > > 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.
>
Just imagine the situation when you don't have a config file, so you have to
use the temp file to create the shmem file. The only way to find that shared
memory is to name that shared memory. Since UNIX doesn't support the named
shmem files it can be done by creating the file /tmp/app_name with the
context that will point to the temp file. Of course you can directly code
that filename to the fixed location and use it but the rest of the world
doesn't have the /tmp.
So my proposal is to do something like this when calling shmem create for
UNIX:
apr_shm_init(filename, NAME)
if there is shmem filename
check if it exists
if does try to delete it
create the file
create the /tmp/apr_NAME
write to the /tmp/apr_NAME filename
if cannot delete
return APR_ENOTOWNER
else
try to open /tmp/apr_NAME
read the context
attach to that file
else
return APR_ENOTFOUND
Of course omitting the NAME forces the code to behave like it does right
now.
MT.
MT.
