[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
