From: "Mladen Turk" <[EMAIL PROTECTED]> Sent: Tuesday, January 08, 2002 12:38 PM
> > > 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. Yes... that corresponds to 'keyed' shared mem. We will be backing by a file for now, and anon will be backed by a key. Anon will be unnamed, so you will have to dup the handle to pass it. That meta-API needs to be determined, not only for shm, but for _ALL_ our handles. Let's leave that aspect alone for a few hours :) I'm overloaded with too many API bits right at this moment. I'm much more worried about having a scoreboard that isn't stuck in place, and can be reopened in the child at a different address. > > > 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. You miss the point. We don't know how the user has chosen to lock. apr_shm's will never need to lock [we presume the code is serialized, and the parent creates the shm/rmm before children begin to stick their fingers in in.] Once it's created, apr_shm has NO NEED for a lock, whatsoever. The users of the contents quite possibly do. But here, we have no idea of what their locking entails. Is it crossproc? crossthread? Only the coder knows, we can't be any help here. If we tried, we would end up forcing them to code into our paper bag. Bill
