apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "'Aaron Bannert'" <aa...@clove.org>
Subject Re: [PROPOSAL] apr_shm_t, a new shared memory API to replace old
Date Tue, 08 Jan 2002 18:04:03 GMT
[My fault for bringing this offlist. Mladen gave me permission to reply
 to his message on the list. All offline material is quoted.]

On Tue, Jan 08, 2002 at 10:12:26AM +0100, Mladen Turk wrote:
> 
> 

[Aaron wrote:]
> > I don't understand what this is for, can you please elaborate?
> > 
> > This API does nothing with locks. It is up to the caller to 
> > provide synchronization if it is needed.
> > 
> > -aaron
> 
> Ok, I'll try.
> 
> I've posted the shmem proposal for the WIN32 couple of months ago, and
> I'm speaking from that point of view.
> 
> When creating shared memory segment you have two choices, either using
> file or anonymous mem segment. Well, the problem with using anonymous
> mem segment is that you still need the name to identify that segment if
> you want to use it across non-child processes.

No, anonymous memory is not for use across non-child processes. If
you want to use memory across unrelated processes you have to make
it name-based.

> If you omit the file name
> in the shmem creation then you obviously want to create the anon shmem,
> but setting the mapping object name could be done only with some kind of
> #define. So you end up with the unique shared name for all applications
> using apr. Generating that name could be done using some sort of
> filename parsing but that would be non user friendly, especially on
> systems using terminal services when one might want to use either
> Global\ or Local\ name spaces.

This may be some weird win32 thing that I don't quite understand, but
from my discussions with OtherBill he seemed to think that the current
API would work for just this purpose.

> The lock I've mentioned is generated from that name, but that could be
> leaved to the caller to cope with, but it would be much elegant to add
> two extra calls to shmem, like apr_shmem_lock/unlock. That way you could
> easily use the apr_rmm alloc scheme.
> 
> Other important usage of locks would be to signal the caller if he's the
> initial owner of that shmem object.

I'm not quite sure how locks came into this discussion, since they are
purposefully excluded from the apr_shm_t API. It is up to the caller to
do their own locking if they wish to synchronize access to a shared memory
segment. Perhaps it will make more sense to continue this discussion in
the context of apr_rmm.

-aaron

Mime
View raw message