BSD mmap for shared memory - am I right?

This is a discussion on BSD mmap for shared memory - am I right? within the Linux Programming forums, part of the Platform Specific Boards category; Originally Posted by brewbuck Shared mapping are still shared after a call to fork(). Here is the proof: That was ...

  1. #16
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by brewbuck View Post
    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...
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  2. #17
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,160
    Quote Originally Posted by sean View Post
    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)
    Last edited by brewbuck; 03-08-2009 at 01:16 PM.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  3. #18
    Super Moderator
    Join Date
    Sep 2001
    Posts
    4,913
    Originally the plan was to have the client process open a log file, write data to it as actions were performed, and then close it when it was done. Of course, in the event that one of the client processes locked up and the server process had to kill it, I wanted the server to be able to fclose() the file without data being lost. Of course that was entirely "theoretical" up until this point, since I hadn't even got shared memory to work - so if files won't work between two processes, I'll have to find another work-around to that.

  4. #19
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    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.
    Last edited by MK27; 03-08-2009 at 05:31 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  5. #20
    Super Moderator
    Join Date
    Sep 2001
    Posts
    4,913
    I'm gonna have to start personally thinking of shared memory the same way as goto: if you think you need it, your program might need redesigning...

    So I have an "input server", a number of "client processes", and whenever there's a client process created, there's an "output server" piped to it (with a named FIFO), which handles the logging and the outputting. So if the "client process" locks up, the input server knows the name of the FIFO, and can also send a specific message to the output server that closes the file and finishes up.

    So the input server just keeps it's own linked list containing the process ID of the client and the name of the FIFO. Then I don't need shared memory - and I only have one process accessing the logs, panels and windows.

  6. #21
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #22
    Super Moderator
    Join Date
    Sep 2001
    Posts
    4,913
    Yeah - when I took a good look at what HAD to be shared - it was WINDOW *'s and PANEL *'s for ncurses (plus that file pointer) - which if I'm not mistaken points to data that's been malloc'ed by ncurses. So that would've been a big problem..

    So thanks for the responses - my apologies to MK 27 who was waiting for me to get mmap working!

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 4
    Last Post: 01-13-2008, 01:14 AM
  2. Question regarding Memory Leak
    By clegs in forum C++ Programming
    Replies: 29
    Last Post: 12-07-2007, 12:57 AM
  3. Memory problem with Borland C 3.1
    By AZ1699 in forum C Programming
    Replies: 16
    Last Post: 11-16-2007, 10:22 AM
  4. Shared Memory - shmget questions
    By hendler in forum C Programming
    Replies: 1
    Last Post: 11-29-2005, 01:15 AM
  5. How much memory may I use?
    By Sloede in forum C Programming
    Replies: 2
    Last Post: 01-08-2004, 07:41 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21