I'm very new to Memory Mapped Files, and I'm a little lost on something.
I know that if I had a file, I could load it and access it from various processes at once using MMaps.
But in my situation, I'm creating a DLL attached to Process A, and that DLL has been given a pointer to a cSurface which Process A has prepared. I need to share that cSurface's data with Process B. I really don't want to have to call up a blank MMap and copy my Process A's surface into it, only to copy it out again in process B.
Is it possible to map my surface as if it were a file so the MMap already points to the surface data when it's created (as it would were I loading SomeTextFile.txt)?
My plan, in theory, would be to receive a pointer to the surface in Proc A, tell windows to share that surface's memory with a given name, and use Mutexes to coordinate access - the idea being that both processes read the same physical copy of the surface with no cumbersome copying.
Is that possible?
Yes, it's all there in the documentation of CreateFileMapping.
You can give your memory mapped file a name. If another process open a mmap with the same name it will point to the same memory. It the handle in CreateFileMapping is put to INVALID_HANDLE_VALUE it keeps it purely in memory. Check the documentation of CreateFileMapping
Thanks for all your comments.
I did some further research and found the answer.
You can use Memory Mapped Files to share either a file, or a blank memory space. If you want to share data already initialised in memory prior to setting up the map, you have to create a blank map and subsequently copy your data into it.
Related
I'm new to libgphoto2 and had some questions about where the actual image memory is located. It seems that photos are accessed via an object called a CameraFile. There's an example included in the source called sample-capture.c that has a function called capture_to_memory.
In that function, a CameraFile object is created and initialized using gp_file_new. The implementation of gp_file_new creates a CameraFile object whose accesstype member is set to GP_FILE_ACCESSTYPE_MEMORY.
That CameraFile object is then passed to gp_camera_file_get, and I'm not really clear what happens in this function.
After the call to gp_camera_file_get, the file is sent to gp_file_get_data_and_size. Looking at the implementation of that function, and given that the files accesstype is GP_FILE_ACCESSTYPE_MEMORY, the gp_file_get_data_and_size function will not allocate any memory and instead merely assign the pointer to the CameraFile's data member (same with size).
So where is the memory this pointer points to? Is it on the actual camera? Or is it somewhere in my ram? I'm just trying to avoid as many memory operations as possible. I've found a nice blog post
http://sepharads.blogspot.com/2011/11/camera-tethered-capturing-using.html?m=1
where the CameraFile object is created via gp_file_new_from_fd. This sets the files accesstype to GP_FILE_ACCESSTYPE_FD. When gp_file_get_data_and_size is called on a file with this accesstype, new memory is allocated and the file's data is copied into it. However, this is read from disk, or at least I assume it is since FD means Unix File Descriptor, and it needs an actual filename string. Does that mean that gp_camera_file_get reads the data into a file on disk if the CameraFile's accestype is GP_FILE_ACCESSTYPE_FD?
There is a function called gp_file_free. If it's an FD file it closes the file handle, but it doesn't call free(file->data) anywhere, so I'm pretty confused...
What does gp_camera_file_get do? The implementation is there, but it kind of threw me. Does it actually bring the file from my camera's memory to my computer's memory and allocate CameraFile->data in ram? Or does it just give me a handle to something stored on my camera?
Sorry if this is the wrong place to ask, I did see some sort of mailing list for libgphoto2 but I couldn't tell how active it was.
Never mind, I think I've found it.
So gp_camera_file_get ends up calling gp_filesystem_get_file, which calls gp_filesystem_get_file_impl. That function looks at the CameraFileType, and if it's GP_FILE_TYPE_NORMAL (which it is, in my case), it calls gp_file_copy with an instance of CameraFileSystemFile as the source.
gp_file_copy ends up calling malloc if GP_FILE_ACCESSTYPE_MEMORY is the destination file's accesstype, and writes to disk if the accesstype is GP_FILE_ACCESSTYPE_FD.
Then, the call to gp_file_free calls gp_file_clean, which calls free if the accesstype is GP_FILE_ACCESSTYPE_MEMORY.
I have a block of memory which I have allocated using mmap. I then want to write this block of memory to a file on the file system. I am wondering if there is a way to point the existing block of memory directly to a file descriptor using mmap() or will I have to copy the whole block of memory to a new mmap() area which has been created with the file descriptor?
You can use vmsplice with SPLICE_F_GIFT to place the memory into a pipe, after that splice or copy_file_range may do what is required.
You will have top copy it, unless you can create the mmap with a temporary file in the first place, and then just rename the file when you want to "save" it.
I'm not familiar with all implementations, I have looked quite closely at the Linux implementation, but I believe this applies in all cases: When you do not have a file when you create a mmap region, the OS will use the "swap" as a file for the mmap region. Since there is a mapping between the file-content and the memory content, you can't trivially just change what that mapping is (although it could, perhaps, be technically possible to achieve, it could be rather "expensive" if you have a 4GB mmap region, where only a small part of it is in physical RAM, the rest is "on disk").
Assuming we're talking pure POSIX, there's no way to attach an mmap'd region to a new fd. I'm also not aware of any way to do this in Linux or OS X.
You'll have to either copy, or mmap the file that you want to write to in the first place. If you don't want the file to appear immediately for some reason, there's the following workaround:
open a temporary file in the filesystem where you want the final file (the same directory is a safe bet)
mmap it, modify it, write out changes
rename the file to its final location.
I'm trying to understand something about HGLOBALs, because I just found out that what I thought is simply wrong.
In app A I GlobalAlloc() data (with GMEM_SHARE|GMEM_MOVABLE) and place the string "Test" in it. Now, what can I give to another application to get to that data?
I though (wrongfully!) that HGLOBALs are valid in all the processes, which is obviously wrong, because HGLOBAL is a HANDLE to the global data, and not a pointer to the global data (that's where I said "OHHHH!").
So how can I pass the HGLOBAL to another application?
Notice: I want to pass just a "pointer" to the data, not the data itself, like in the clipboard.
Thanks a lot! :-)
(This is just a very long comment as others have already explained that Win32 takes different approach to memory sharing.)
I would say that you are reading into books (or tutorials) on Windows programming which are quite old and obsolete as Win16 is virtually dead for quite some time.
16-bit Windows (3.x) didn't have the concept of memory isolation (or virtual /flat/ address space) that 32-bit (and later) Windows versions provide. Memory there used to be divided into local (to the process) and global sections, both living in the same global address space. Descriptors like HGLOBAL were used to allow memory blocks to be moved around in physical memory and still accessed correctly despite their new location in the address space (after proper fixation with LocalLock()/GlobalLock()). Win32 uses pointers instead since physical memory pages can be moved without affecting their location in the virtual address space. It still provides all of the Global* and Local* API functions for compatibility reasons but they should not be used anymore and usual heap management should be used instead (e.g. malloc() in C or the new operator in C++). Also several different kind of pointers existed on Win16 in order to reflect on the several different addressing modes available on x86 - near (same segment), far (segment:offset) and huge (normalised segment:offset). You can still see things like FARPTR in legacy Win16 code that got ported to Win32 but they are defined to be empty strings as in flat mode only near pointers are used.
Read the documentation. With the introduction of 32-bit processing, GlobalAlloc() does not actually allocate global memory anymore.
To share a memory block with another process, you could allocate the block with GlobalAlloc() and put it on the clipboard, then have the other process retreive it. Or you can allocate a block of shared memory using CreateFileMapping() and MapViewOfFile() instead.
Each process "thinks" that it owns the full memory space available on the computer. No process can "see" the memory space of another process. As such, normally, nothing a process stores can be seen by another process.
Because it can be necessary to pass information between processess, certain mechanisms exists to provide this functionality.
One approach is message passing; one process issues a message to another, for example over a pipe, or a socket, or by a Windows message.
Another is shared memory, where a given block of memory is made available to two or more processes, such that whatever one process writes can be seen by the others.
Don't be confused with GMEM_SHARE flag. It does not work the way you possibly supposed. From MSDN:
The following values are obsolete, but are provided for compatibility
with 16-bit Windows. They are ignored.
GMEM_SHARE
GMEM_SHARE flag explained by Raymond Chen:
In 16-bit Windows, the GMEM_SHARE flag controlled whether the memory
should outlive the process that allocated it.
To share memory with another process/application you instead should take a look at File Mappings: Memory-mapped files and how they work.
I currently try to implement some interprocess communication using the Windows CreateFileMapping mechanism. I know that I need to create a file mapping object with CreateFileMapping first and then create a pointer to the actual data with MapViewOfFile. The example then puts data into the mapfile by using CopyMemory.
In my application I have an image buffer (1 MB large) which I want to send to another process. So now I inquire a pointer to the image and then copy the whole image buffer into the mapfile. But I wonder if this is really necessary. Isn't it possible to just copy an actual pointer in the shared memory which points to the image buffer data? I tried a bit but didn't succeed.
Different processes have different address spaces. If you pass a valid pointer in one process to another process, it will probably point to random data in the second process. So you will have to copy all the data.
I strongly recommend you use Boost::interprocess. It has lots of goodies to manage this kind of stuff & even includes some special Windows-only functions in case you need to interoperate w/ other processes that use particular Win32 features.
The most important thing is to use offset pointers rather than regular pointers. Offset pointers are basically relative pointers (they store the difference between where the pointer is and where the thing pointed to is). This means that even if the two pointers are mapped to different address spaces, as long as the mappings are identical in structure then you are fine.
I've used all kinds of complicated data structures with offset smart pointers and it worked like a charm.
Shared Memory doesn't mean sending and receiving of Data. Its a memory created for number of processes without violation. For that you have to follow some mechanisms like locks so that the data will not corrupt.
In process 1 :
CreateFileMapping() : It will create the Shared Memory Block, with the name provided in last parameter, if it is not already present and returns back a handle (you may call it a pointer), if successful.
MapViewOfFile() : It maps (includes) this shared block in the process address space and returns a handle (again u can say a pointer).
With this pointer returned by MapViewOfFile() only you can access that shared block.
In process 2 :
OpenFileMapping() : If the shared memory block is successfully created by CreateFileMapping(), you can use it with the same name (name used to create the shared memory block).
UnmapViewOfFile() : It will unmap (you can remove the shared memory block from that process address space). When you are done using the shared memory (i.e. access, modification etc) call this function .
Closehandle() : finally to detach the shared memory block from process , call this with argument,handle returned by OpenFileMapping() or CreateFileMapping().
Though these functions look simple, the behaviour is tricky if the flags are not selected properly.
If you wish to read or write shared memory, specify PAGE_EXECUTE_READWRITE in CreateFileMapping().
Whenever you wish to access shared memory after creating it successfully, use FILE_MAP_ALL_ACCESS in MapViewOfFile().
It is better to specify FALSE (do not inherit handle from parent process) in OpenFileMapping() as it will avoid confusion.
You CAN get shared memory to use the same address over 2 processes for Windows. It's achieveable with several techniques.
Using MapViewOfFileEx, here's the significant experpt from MSDN.
If a suggested mapping address is
supplied, the file is mapped at the
specified address (rounded down to the
nearest 64K-boundary) if there is
enough address space at the specified
address. If there is not enough
address space, the function fails.
Typically, the suggested address is
used to specify that a file should be
mapped at the same address in multiple
processes. This requires the region of
address space to be available in all
involved processes. No other memory
allocation can take place in the
region that is used for mapping,
including the use of the VirtualAlloc
or VirtualAllocEx function to reserve
memory.
If the lpBaseAddress parameter
specifies a base offset, the function
succeeds if the specified memory
region is not already in use by the
calling process. The system does not
ensure that the same memory region is
available for the memory mapped file
in other 32-bit processes.
Another related technique is to use a DLL with a section marked Read + Write + Shared. In this case, the OS will pretty much do the MapViewOfFileEx call for you and for any other process which loads the DLL.
You may have to mark your DLL to a FIXED load address, not relocateable etc.. naturally.
You can use Marshalling of pointers.
If it's possible, it would be best to have the image data loaded/generated directly into the shared memory area. This eliminates the memory copy and puts it directly where it needs to be. When it's ready you can signal the other process, giving it the offset into your shared memory where the data begins.
I would like to pass a pointer (I am putting a file with data in memory with mmap) to processes spawned using fork + exec, but I am stuck on how to pass a pointer to the exec() spawned process?
UPDATE1:
Thanks for your inputs, I do use shared memory creating it with mmap with MAP_INHERIT flag:
Each mapped file and shared memory region created with the mmap() function
is unmapped by a successful call to any of the exec functions, except those
regions mapped with the MAP_INHERIT option. Regions mapped with the
MAP_INHERIT option remain mapped in the new process image.
source: http://www.uwm.edu/cgi-bin/IMT/wwwman?topic=exec(2)&msection=
UPDATE2:
This is homework excercise, but I think I must stop thinking about pointers and think about the IPC itself. I guess I will go with trying to mmap the same file in child process.
Short code example much appreciated.
Thanks in advance for your help.
If you use shared memory, you can't pass the pointer. The pointer will contain the virtual address, which is different from one process to another. You have to exchange offset values, based on the start of the shared memory area.
If you don't use shared memory, you can't exchange pointers of any kind: The other process won't be able to access the memory of your process.
This can't work. The new process should mmap the file itself as well.
The spawned process should probably open a pipe back to the parent process and ask for the data it needs to map the shared memory segment.
Alternatively you can use boost::interprocess to create a shared memory segment for you and actually pass around the address (it can do the mapping). You're on your own reading that documentation though: http://www.boost.org/doc/libs/1_38_0/doc/html/interprocess.html
Consider passing the offset to the memory within the file to the child process. If the offset is zero, then don't bother, but if you need to pass a 'pointer' to part way through the file, then convert that to an offset from the start address, and pass that to the child. The child can then get to the data by adding the offset to the address it obtains for the mapped file.
Just pass as text in command-line argument, or in environment variable.
This is a big area, and you have a lot to choose from.
The key finding those solution is to search for something like Linux inter processor communication or maybe Linux IPC.
A intro into IPC can also be found in books like, Advance Linux Programming (ISBN: 0-7357-1043-0)