apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mladen Turk" <mt...@mappingsoft.com>
Subject Re: [PROPOSAL] apr_shm_t, a new shared memory API to replace old
Date Tue, 08 Jan 2002 22:54:35 GMT

----- Original Message -----
From: "Ryan Bloom" <rbb@covalent.net>
To: "William A. Rowe, Jr." <wrowe@covalent.net>; "Mladen Turk"
<mturk@mappingsoft.com>; "'Aaron Bannert'" <aaron@clove.org>
Cc: <dev@apr.apache.org>
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
> 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
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
    try to open /tmp/apr_NAME
         read the context
         attach to that file
        return APR_ENOTFOUND

Of course omitting the NAME forces the code to behave like it does right



View raw message