lkml.org 
[lkml]   [1998]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: shared memory deallocation
    Date
    > Umm, yeah. That's what it's supposed to do. Shared memory is supposed to
    > be persistant, so that you can access it from other processes even if no
    > processes have been using it in the meantime.

    One thing that many people may not be aware of (it seems to surprise
    many people when I mention it) is that IPC shared memory has reference
    counters. This means you can use IPC_RMID on a shared memory ID after
    attaching to the memory and still access the pointer. When the process
    exits the shared memory allocation goes away. Shared memory allocated
    in this way is inherited by child processes but can't be attached to
    from other processes. (this is analogous to closing a file after using
    mmap() and still being able to access the memory).

    So, if what you are doing is setting up shared memory before a fork()
    then remember to RMID it and you won't have to have any annoying
    scripts that parse the output of ipcs to free up memory.

    Example of how to do this (and how to use 3 other mechanisms to obtain
    shared memory that work on various OSes) is available from
    ftp://samba.anu.edu.au/pub/tridge/misc/shm_sample.c. I wrote that
    after the Nth person asked me about shared memory ...

    some people may also be interested in
    ftp://samba.anu.edu.au/pub/tridge/misc/semspeed.c which shows an
    enormous difference in the speed of SysV semaphores vs fcntl for
    locking on various OSes.

    Cheers, Andrew

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu

    \
     
     \ /
      Last update: 2005-03-22 13:42    [W:0.021 / U:59.536 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site