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 Wed, 09 Jan 2002 04:41:58 GMT
From: "William A. Rowe, Jr." <wrowe@covalent.net>
Sent: Tuesday, January 08, 2002 5:02 PM

> From: "Mladen Turk" <mturk@mappingsoft.com>
> Sent: Tuesday, January 08, 2002 4:54 PM
> > 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. 
> Mladen, that is nonportable.  Ergo the suggestion is vetoed.

Let me clarify.

You must always have a common _file_ that identifies the apr_shm.  Now there are
two approaches as Ryan pointed out.  One is to _back_ the apr_shm by that file
[file-based shm].  That's what we do in Win32 now.

The other option is key-based.  I am not adverse to adding an apr_int32_t flags
arg to apr_shm_create()/attach(), that could request a filebased or keybased

key-based shm is really pagefile-backed shm, with a key identifier.  The api would
create an anonymous apr_shm_t, query WinNT for the internal ID assigned to the
anonymous region, and write that key to the given file.  Callers to attach() cause
apr_shm to read that file, retrieve that key and open the anonymous named mapping.

No duplicate names, since we let the kernel name the mapping object.

We also need to create an os_get/os_put for the mapping object handle, so you could
call DuplicateHandle and pass it between processes.  In fact, I am looking forward
to creating an apr_type duplicator that would do just that, for multiple apr types.


View raw message