----- Original Message ----- From: "'Aaron Bannert'" <[EMAIL PROTECTED]> To: "Mladen Turk" <[EMAIL PROTECTED]> Cc: <[email protected]> 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. MT.
