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 19:53:28 GMT
From: "Mladen Turk" <mturk@mappingsoft.com>
Sent: Tuesday, January 08, 2002 1:37 PM


> The locking I was thinking of was in the pupose to determine the initial
> owner status, in the case you have couple of services comunicating with each
> other. So that lock (not the apr_proc_mutex_create but CreateMutex(NULL,
> TRUE, somename)) will give that info and the coder could decide to cope with
> that fact.

This sounds like a problem with apr_proc_mutex_create.  If you are using
CreateMutex, then you are already non-portable.  Understand APR is build for
portability, I'm looking at apr_proc_mutex_create's enum arg and already
weeping :-/  Again, if you want to wrap your create apr_shm logic within a
lock, that's the coder's choice.  It doesn't make sense for APR.  If you
called create, you are the owner, if you called attach, then you are the
user.  Create will fail if the backing file already exists, that's for 
certain.

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.

ITMT, we could not implement any shm on win32 with the old apr_shmem.h 
methodology, so we are trying to make forward progress.

Bill


Mime
View raw message