Thread: BSD mmap for shared memory - am I right?

Originally Posted by brewbuck

Shared mapping are still shared after a call to fork(). Here is the proof:

That was great brewbuck; what I was hoping sean would eventually figure out and demonstrate because I've been too lazy to try...

Originally Posted by sean

The problem I see myself having, however, is storing an expandable linked list (containing mainly file descriptors, pointers, and a pid) in that kind of structure...

edit: appears I have to use offsets instead of the "next" and "prev" pointers... niice...

I only noticed this now, but why would you store file descriptors in a shared memory segment? They will only be meaningful to a single process. If you fork(), the same descriptors are shared between parent and child, but this is not true in general. And any descriptors created after the fork() will not be shared, even between parent and child. (You can achieve this sharing with clone() and CLONE_FILES but that's not what fork() does)

Here's an even crazier idea (although I can't express how hopeful I am for you; I even lit little candles today that say "sean--mmap" in cursive on them):

Start a local socket server (PF_LOCAL) and have all the children connect to it as clients. Everyone starts with a copy of the data relevant to them, then work out some signals for making sure everyone stays abreast of what they need to, via the cleverness of the parent. Once you have a few general functions worked out, "the local socket" will work as fast as the front side bus (or whatever that thing is called).

I mean, correct me if I'm wrong but there must be a gizzillion super-complex database setups that work continuously over the internet, which means nothing but what passes thru a socket.

There are cases where shared memory is very much useful - a particular case is some sort of "database" where the data is rarely or never changed, that is shared between applications. A typical example would be a font-server. Font's aren't exactly changing rapidly (you may find that different sizes and typefaces are being used at different times, but the names of fonts and the ones available in a particular system tends to be pretty constant over time).

One could also consider "sharing one-writer many readers data", e.g. a multiplayer game could have a shared memory section where each player has a "slot" in a shared memory to update their own players position and actions with others. All players can read other players, but each player will only ever modify their own data (this may include data that informs the other players to update their player, e.g. transfer of ownership of items, fighting that results in damage, etc).

But for your average "I want this data to be transferred from here to there", then shared memory is probably not the right thing to do.

--
Mats