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 18:38:57 GMT

----- Original Message -----
From: "'Aaron Bannert'" <aaron@clove.org>
To: "Mladen Turk" <mturk@mappingsoft.com>
Cc: <dev@apr.apache.org>
Sent: Tuesday, January 08, 2002 7:04 PM
Subject: Re: [PROPOSAL] apr_shm_t, a new shared memory API to replace old

> > Ok, I'll try.
> > 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.

Yes, that's my point. Anonymous shmem can be cross-process (on WIN32) if you
give it the name, then instead using regular file it will be backed up by
the system paging file. So, you need to name it.

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

Perhaps it would, but only in the context of the alloc/free synchronization.


View raw message