show me where I said that.Originally Posted by brewbuck
without going into ANY detail about what you meant.
show me where I said that.
without going into ANY detail about what you meant.
in the parent I fork first, seeing as how it's pointless to allocate shared memory if no child process is created, and then create and attach the shared memory. once in the child process, I call shmget() and shmat(), using the same key (child PID + 0x10000000). I thought of one possible reason this could be happening. in the parent process, I have a thread running that monitors and acts upon the shared memory segments (one per child). when I free shared memory in the parent, I'm doing it from within this thread. is it possible that it's remaining attached in the main thread of the parent process, while being detached from the thread?
The kernel keeps its own copy of the shmid_ds strcuture associated with the shmid - so attachment counts are system-wide.
The reason I ask is because in SunOS/Solaris/AIX documentation, it explicitly states that children of fork() inherit existing attachments and the associated shm_nattach member of shmid_ds is incremented by 1 as a result of calling fork().
I don't know if this is the case on your system. If it were, then the following call order would be bad:
- parent-attach (++shm_nattach)
- fork (++shm_nattach)
- child-attach (++shm_nattach)
Since you say you're calling fork() fist, then this shouldn't be a problem.
gg
I had assumed that since you were working with SHM, you must have already understood memory mapped files. Since that assumption was wrong, I'll explain.
Instead of a SHM segment with an identifier, you have a file in the filesystem. The identifier is the file path. Suppose you wanted to share a 10 megabyte segment between multiple processes. You create the segment by creating a file in the filesystem of size 10M. Call it /path/to/segment.
Then each process which wants to share that 10 megabyte space will open() the /path/to/segment file. Then, using the file descriptor returned, they would call mmap() to map that 10 megabyte space into their address space. At that point, the memory can be accessed just like a SHM segment. All the processes will see all changes to that memory.
The memory itself is cached on disk in the /path/to/segment file. This file will not be deleted by the operating system. So it "sticks around" like a SHM segment, but it sticks around on disk, not in memory, so it's nowhere near as much of a problem if nobody deletes it.
The performance of shared mmaps is identical to that of SHM segments.
You can read the man page for mmap() to figure out how to call it, and I'd be happy to answer questions about it.
I hope this little disagreement will have no lasting effect on our relationship. I'm fairly new to this board, and certainly don't want any bad blood with fellow posters. I'm willing to let this all be water under the bridge.
I'll look into it, but at this point, I'm not sure if it's really the ideal thing to use for my application, since I only allocate 32 bytes for each child process, and could potentially have hundreds of clients connected to the server. this could eat up disk space very quickly, considering that a file must allocate one whole block on the disk, and could have a lot of overhead, even if the block size was only 512 bytes.
