This module is an interface to mmap(2) system call under POSIX (Unix, Linux, Mac OS X) and CreateFileMapping, MapViewOfFile under Windows.

We can consider mmap as lazy IO pushed into the virtual memory subsystem.

It is only safe to mmap a file if you know you are the sole user. Otherwise referential transparency may be or may be not compromised. Sadly semantics differ much between operating systems.

In case of IO errors all function use throwErrno or throwErrnoPath.

In case of ForeignPtr or ByteString functions the storage manager is used to free the mapped memory. When the garbage collector notices there are no further references to the mapped memory, a call to munmap is made. It is not necessary to do this yourself. In tight memory situations it may be profitable to use System.Mem.performGC or finalizeForeignPtr to force an unmap action. You can also use mmapWithFilePtr that uses scope based resource allocation.

To free resources returned as Ptr use munmapFilePtr.

For modes ReadOnly, ReadWrite and WriteCopy file must exist before mapping it into memory. It also needs to have correct permissions for reading and/or writing (depending on mode). In ReadWriteEx the file will be created with default permissions if it does not exist.

If mode is ReadWrite, ReadWriteEx or WriteCopy the returned memory region may be written to with poke and friends. In WriteCopy mode changes will not be written to disk. It is an error to modify mapped memory in ReadOnly mode. If is undefined if and how changes from external changes affect your mmapped regions, they may reflect in your memory or may not and this note applies equally to all modes.

Range specified may be Nothing, in this case whole file will be mapped. Otherwise range should be 'Just (offset,size)' where offsets is the beginning byte of file region to map and size tells mapping length. There are no alignment requirements. Returned Ptr or ForeignPtr will be aligned to page size boundary and you'll be given offset to your data. Both offset and size must be nonnegative. Sum offset + size should not be greater than file length, except in ReadWriteEx mode when file will be extended to cover whole range. We do allow size to be 0 and we do mmap files of 0 length. If your offset is 0 you are guaranteed to receive page aligned pointer back. You are required to give explicit range in case of ReadWriteEx even if the file exists.

File extension in ReadWriteEx mode seems to use sparse files whenever supported by oprating system and therefore returns immediatelly as postpones real block allocation for later.

For more details about mmap and its consequences see:

• http://opengroup.org/onlinepubs/009695399/functions/mmap.html
• http://www.gnu.org/software/libc/manual/html_node/Memory_002dmapped-I_002fO.html
• http://msdn2.microsoft.com/en-us/library/aa366781(VS.85).aspx

Questions and Answers

• Q: What happens if somebody writes to my mmapped file? A: Undefined. System is free to not synchronize write system call and mmap so nothing is sure. So this might be reflected in your memory or not. This applies even in WriteCopy mode.
• Q: What happens if I map ReadWrite and change memory? A: After some time in will be written to disk. It is unspecified when this happens.
• Q: What if somebody removes my file? A: Undefined. File with mmapped region is treated by system as open file. Removing such file works the same way as removing open file and different systems have different ideas what to do in such case.
• Q: Why can't I open my file for writting after mmaping it? A: File needs to be unmapped first. Either make sure you don't reference memory mapped regions and force garbage collection (this is hard to do) or better yet use mmaping with explicit memory management.
• Q: Can I map region after end of file? A: You need to use ReadWriteEx mode.