How to share memory created by mmap
rbfish
How can I share a shared memory, created with mmap(MAP_ANON|
MAP_SHARED), between unrelated processes?
For example, one progress creates a shared memory with mmap(MAP_ANON|
MAP_SHARED). How can I tell the other processes the shared memory? And
then the other processes can access the same shared memory.
Thanks in advance.
Rainer Weikusat
> How can I share a shared memory, created with mmap(MAP_ANON|
> MAP_SHARED), between unrelated processes?
Not at all. There is (meanwhile) a UNIX(*)-interface for this, namely,
shm_open. Otherwise, the other processes either need to inherit the
mapping via fork(2) or a named file must be used instead (which other
processes can open and also mmap).
rbfish
Marcel Bruinsma
Just out of curiosity; if the processes are on the same machine,
couldn't you send (sendmsg) a file descriptor as auxiliary data,
and use that as an mmap parameter?
--
printf -v email $(echo \ 155 141 162 143 145 154 142 162 165 151 \
156 163 155 141 100 171 141 150 157 157 056 143 157 155|tr \ \\\\)
# Live every life as if it were your last! #
Rainer Weikusat
> Rainer Weikusat schrieb:
>> rbfish <rbfi...@gmail.com> writes:
>>> How can I share a shared memory, created with mmap(MAP_ANON|
>>> MAP_SHARED), between unrelated processes?
>>
>> Not at all. There is (meanwhile) a UNIX(*)-interface for this, namely,
>> shm_open. Otherwise, the other processes either need to inherit the
>> mapping via fork(2) or a named file must be used instead (which
>> other processes can open and also mmap).
>
> Just out of curiosity; if the processes are on the same machine,
> couldn't you send (sendmsg) a file descriptor as auxiliary data,
> and use that as an mmap parameter?
Ich beantworte das mal in Deutsch bevor sich jemand darueber beschwert
;-): Bei MAP_ANON(YMOUS) gibt es keinen Dateibeschreiber, den man an
andere Prozesse uebermitteln koennte, vgl
MAP_ANONYMOUS
The mapping is not backed by any file; its
contents are initialized to zero. The fd and
offset arguments are ignored; however, some
implementations require fd to be -1 if
MAP_ANONYMOUS (or MAP_ANON) is specified, and
portable applications should ensure this.
[mmap(2)/ Linux]
'Some implementations' enthalten wenigstens FreeBSD 7.2,
Marcel Bruinsma
> Marcel Bruinsma <we-love-...@gmail.com> writes:
>> Rainer Weikusat schrieb:
>>> rbfish <rbfi...@gmail.com> writes:
>>>> How can I share a shared memory, created with mmap(MAP_ANON|
>>>> MAP_SHARED), between unrelated processes?
>>>
>>> Not at all. There is (meanwhile) a UNIX(*)-interface for this,
>>> namely, shm_open. Otherwise, the other processes either need to
>>> inherit the mapping via fork(2) or a named file must be used instead
>>> (which other processes can open and also mmap).
>>
>> Just out of curiosity; if the processes are on the same machine,
>> couldn't you send (sendmsg) a file descriptor as auxiliary data,
s/auxiliary/ancillary/
>> and use that as an mmap parameter?
>
> Bei MAP_ANON(YMOUS) gibt es keinen Dateibeschreiber, den man
> an andere Prozesse uebermitteln koennte, vgl
Die Frage bezog sich auf »named file«. Prozeß A, zB:
open("foo")
unlink("foo")
ftruncate()
mmap()
Prozeß B erhält den Dateibeschreiber von A,
recvmsg()
mmap()
Nur ein Gedankenspiel, als ersatz für shm_open
taugt das selbstverständlich nicht.
Rainer Weikusat
> Rainer Weikusat wrote:
>
>> Marcel Bruinsma <we-love-...@gmail.com> writes:
>>> Rainer Weikusat schrieb:
>>>> rbfish <rbfi...@gmail.com> writes:
>>>>> How can I share a shared memory, created with mmap(MAP_ANON|
>>>>> MAP_SHARED), between unrelated processes?
>>>>
>>>> Not at all. There is (meanwhile) a UNIX(*)-interface for this,
>>>> namely, shm_open. Otherwise, the other processes either need to
>>>> inherit the mapping via fork(2) or a named file must be used instead
>>>> (which other processes can open and also mmap).
>>>
>>> Just out of curiosity; if the processes are on the same machine,
>>> couldn't you send (sendmsg) a file descriptor as auxiliary data,
> s/auxiliary/ancillary/
>>> and use that as an mmap parameter?
>>
>> Bei MAP_ANON(YMOUS) gibt es keinen Dateibeschreiber, den man
>> an andere Prozesse uebermitteln koennte, vgl
>
> open("foo")
> unlink("foo")
> ftruncate()
> mmap()
> recvmsg()
> mmap()
Das ist natuerlich moeglich. Aber schon die Handhabung von 'ancillary
data' alleine ist ausreichend aufwendig, dass man diese meiner Ansicht
nach eher vermeiden sollte. Dazu kommt dann noch die Komplikation,
einen geeigneten IPC-Kanal (PF_UNIX-socket) zur Verfuegung stellen zu
muessen.
> Nur ein Gedankenspiel, als ersatz f�r shm_open taugt das
> selbstverst�ndlich nicht.
shm_open kann durchaus als library-wrapper fuer open implementiert
sein. Folgendes Programm:
#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>
int main(void)
{
int fd;
fd = shm_open("/test", O_RDWR | O_CREAT, 0600);
pause();
return 0;
}
Gibt hier (Debian/ Linux 2.6.30) folgende (relevanten) strace-Ausgabe:
statfs("/dev/shm/", {f_type=0x1021994, f_bsize=4096, f_blocks=56240, f_bfree=56240, f_bavail=56240, f_files=56240, f_ffree=56238, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
futex(0xb7fb7200, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/dev/shm/test", O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0600) = 3
fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
pause(