Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <056c01c198ca$2c1f0250$93c0b0d0@v505>
From: "William A. Rowe, Jr." <wrowe@covalent.net>
To: <dev@apr.apache.org>
References: <20020108002539.D1529@clove.org>
 <20020108210412.E12CD46E02@koj.rkbloom.net>
 <02c301c1988d$6f8d33a0$93c0b0d0@v505>
 <20020108220052.F1FC646E02@koj.rkbloom.net>
 <00ec01c19897$776d25d0$5f00000a@armada> <033a01c19899$8eb8f9b0$93c0b0d0@v505>
 <053a01c198c8$7b9a8590$93c0b0d0@v505>
Subject: Re: [PROPOSAL] apr_shm_t, a new shared memory API to replace old
Date: Tue, 8 Jan 2002 22:57:39 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

From: "William A. Rowe, Jr." <wrowe@covalent.net>
Sent: Tuesday, January 08, 2002 10:41 PM


> 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
> apr_shm_t.

It goes without saying [so I'm saying it] that we would have APR_SHM_DEFAULT,
APR_SHM_KEYBASED and APR_SHM_FILEBASED options, and if you pass a different flag
value to the attach() than was passed to create(), you've horked yourself.  And
without a filename, the non-APR_SHM_DEFAULT options would fail or be ignored.

The reason I suggested the flags now, before the API is widely adopted, is that
an APR_SHM_READONLY to attach() would be extremely useful for debugging some
shm applications.  Even if some platforms ignored the flag because they could
not support it, we would still profit by other platforms noting the bugs.  This
was the same theory I applied when I wrote the original patch to allow apr_pool's
to be transformed to read-only.

Bill