# Memory mapped files in Fortran?

**URL:** <https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178>\
**Category:** Language enhancement\
**Created:** [January 12, 2024, 8:10pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178 "2024-01-12T20:10:29Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [January 12, 2024, 8:10pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/1 "2024-01-12T20:10:30Z")

</div>

C has memory mapped files. Among different possible usages they allow:

- accessing the content of a file as if it was an array in memory
- allocating very large arrays beyond the RAM+swap size: the content is basically on disk and cached in RAM; of course there’s no magic and it can’t be as fast as having the content only in RAM, but in some cases (and assuming fast disks such as SSDs) the performance penalty can be relatively limited

Would it be possible to get these features in Fortran? Or is it too OS-dependent, and therefore non portable?

```auto
real, allocatable :: a(:)
open(unit=lu,file="foo.bin",form="unformatted")
allocate( a(n), mmap=lu )

```

---

<div class="post-metadata">

**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\
**Post date:** [January 12, 2024, 11:25pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/2 "2024-01-12T23:25:59Z")

</div>

You can open a file with `access="direct"` and `recl=something`. Getting the file to have the correct size I’m not as sure about. I haven’t had much reason to use them. Anyway, we already have this with direct access files.

---

<div class="post-metadata">

**Author:** ![nja](https://avatars.discourse-cdn.com/v4/letter/n/ed8c4c/32.png) [@nja](https://fortran-lang.discourse.group/u/nja)\
**Post date:** [January 13, 2024, 7:14am UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/3 "2024-01-13T07:14:23Z")

</div>

A memory mapped file can also be accessed by several processes. It’s a way to share data between processes, very different from message queues or pipes.

Having this would be incredible. The memory mapped file system APIs are generally not trivial to use, so having this bundled in the language would be great!

The implementation is OS-dependent, but the concept exists in all platforms I know. I don’t feel that’s an argument against: ˋdo concurrent` concrete implementation is highly OS-dependent too.

Many languages have OS-dependent features: in Python, the function to open a shared memory file has a different signature between Windows and Linux ([mmap — Memory-mapped file support — Python 3.12.1 documentation](https://docs.python.org/3/library/mmap.html?highlight=mmap#mmap.mmap)). On systems without memory mapped files, the module is simply absent (micropython for example).

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [January 13, 2024, 8:46am UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/4 "2024-01-13T08:46:27Z")

</div>

> [@nja](#):
>
> A memory mapped file can also be accessed by several processes. It’s a way to share data between processes, very different from message queues or pipes.

Yes, I have used them only in the cases described above, but there are more more potential applications.

> [@nja](#):
>
> Many languages have OS-dependent features: in Python, the function to open a shared memory file has a different signature between Windows and Linux ([mmap — Memory-mapped file support — Python 3.12.1 documentation](https://docs.python.org/3/library/mmap.html?highlight=mmap#mmap.mmap)). On systems without memory mapped files, the module is simply absent (micropython for example).

Indeed in Fortran it could be an optional module `ISO_MMAP`

> [@everythingfunctional](#):
>
> You can open a file with `access="direct"` and `recl=something`. Getting the file to have the correct size I’m not as sure about. I haven’t had much reason to use them. Anyway, we already have this with direct access files.

OK, but it’s not as flexible. For instance I had a recent case in C where a bunch of large arrays where needed, but the code had also to be able to run on machines with limited RAM. So for these arrays we just did something like:

```auto
if (enough_ram) arr = malloc(...) else arr = mmap(...);

```

And we didn’t have to change a single line in the rest of the code. In our case the performance penalty was acceptable (30% slower), because the array were accessed sequentially with many computations on chunks that were already in cache.

Granted, memory mapping can probably be used in Fortran through C interoperability, but generally speaking I prefer having the useful features directly native in the language.

By the way, to quickly get a file of the desired size (say `n` default reals) I would write:

```auto
open(newunit=lu, file="foo.bin", acces="stream")
write(lu, pos=n*storage_size(0.0)/file_storage_size) 0.0

```

---

<div class="post-metadata">

**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\
**Post date:** [January 15, 2024, 7:54pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/5 "2024-01-15T19:54:48Z")

</div>

> [@PierU](#):
>
> So for these arrays we just did something like:
> 
> ```auto
> if (enough_ram) arr = malloc(...) else arr = mmap(...);
> 
> ```
> 
> And we didn’t have to change a single line in the rest of the code.

In that case you could probably do something like

```auto
real, pointer :: arr(:)

call c_f_pointer(c_ptr=c_get_mem(...), fptr=arr, shape=[...])

```

```C
void* c_get_mem(...) {
  return enough_ram ? malloc(...) : mmap(...);
}

```

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [January 15, 2024, 9:34pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/6 "2024-01-15T21:34:45Z")

</div>

> [@PierU](#):
>
> Granted, memory mapping can probably be used in Fortran through C interoperability, but generally speaking I prefer having the useful features directly native in the language.

😉

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [January 15, 2024, 11:14pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/7 "2024-01-15T23:14:03Z")

</div>

I played with this briefly in the past, using the C route. My motivation were memory-mapped arrays following this paper:

> Rojc, B., & Depolli, M. (2021). A Resizable C++ Container using Virtual Memory. In _ICSOFT_ (pp. 481-488).  
> [https://www.scitepress.org/Papers/2021/105571/105571.pdf](https://www.scitepress.org/Papers/2021/105571/105571.pdf)

My experiment can be found here: [Virtual memory array in Fortran based on POSIX system headers · GitHub](https://gist.github.com/ivan-pi/6097d71bb1512b967008c0362f6f40cc). I admit I didn’t fully read the documentation for [mmap](https://man7.org/linux/man-pages/man2/mmap.2.html) and just blindly followed the article. I copied the parameter values out of `mman.h` header file on my Mac.

The purpose of the original work above was to use the mmap-ed container for fast-generation of point clouds, as described in:

> Depolli, M., Slak, J., & Kosec, G. (2022). Parallel domain discretization algorithm for RBF-FD and other meshless numerical methods for solving PDEs. _Computers & Structures_, _264_, 106773. [https://doi.org/10.1016/j.compstruc.2022.106773](https://doi.org/10.1016/j.compstruc.2022.106773)

* * *

Another interesting use of memory-mapped arrays is for cyclic buffers. An example can be found in the following work (not easy reading):

> Kummerländer, A., Dorn, M., Frank, M., & Krause, M. J. (2023). Implicit propagation of directly addressed grids in lattice Boltzmann methods. _Concurrency and Computation: Practice and Experience_, _35_(8), e7509. [https://doi.org/10.1002/cpe.7509](https://doi.org/10.1002/cpe.7509)

* * *

Concerning the syntax, vendors already implement extensions to the `open` statement. For example if you look at Intel’s documentation, the items in green are Intel-specific: [OPEN Statement Specifiers](https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2024-0/open-statement-specifiers.html). But I don’t think any vendor has extensions in the `allocate` statement.

Is there a particular reason you want the memory mapping to work with **allocatable arrays**? In your snippet,

```auto
open(unit=lu,file="foo.bin",form="unformatted")
allocate( a(n), mmap=lu )

```

does `n` take on the value from the file, or does it provide access to up to `n` elements?

With pointer arrays, in principle you could do something like:

```fortran
real, pointer :: mm_a(:) ! prefix with mm_, so we remember to deallocate

call mmap_from_file("foo.bin",mm_a)
! ...
call mmap_destroy(mm_a)

```

The caller need not know that this is a OS-specific feature implemented using C-binding.

A slightly-more complicated option, would be to make the mapped file it’s own type [a la Boost](https://www.boost.org/doc/libs/1_84_0/libs/iostreams/doc/classes/mapped_file.html):

```fortran
type(mapped_file) :: mfile
real, pointer :: mm_a(:)

mfile = mapped_file(filename,action="readwrite"[,length=maxlength,offset=0])
call mmap_from_file(mfile,mm_a)
if (associated(mm_a)) then
   ! ...
end if
nullify(mm_a)

! finalizer takes care of closing mfile

```

Pointer arrays, and subroutines are both _native_ elements of Fortran. Something like this could surely find a home in the [Fortran stdlib](https://github.com/fortran-lang/stdlib).

> [@PierU](#):
>
> And we didn’t have to change a single line in the rest of the code.

The reason that solution worked well in C is because in C arrays are typically just pointers to the initial element, not because `mmap` would be a native part of C. I’d also expect you’d have to change at least a second line:

```cpp
if (enough_ram) free(arr) else munmap(arr,...);

```

So I think with pointer arrays you can replicate what you had in C:

```fortran
real, pointer :: a(:)
if (enough_ram) then
   allocate(a(n))
else
   call mmap(...)
end if

! ... use a ...
! not a single line needs to change

if (enough_ram) then
   deallocate(a)
else
   call munmap(...)
end if

```

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [January 16, 2024, 7:49am UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/8 "2024-01-16T07:49:57Z")

</div>

> [@ivanpribec](#):
>
> Is there a particular reason you want the memory mapping to work with **allocatable arrays**? In your snippet,
> 
> ```auto
> open(unit=lu,file="foo.bin",form="unformatted")
> allocate( a(n), mmap=lu )
> 
> ```
> 
> does `n` take on the value from the file, or does it provide access to up to `n` elements?

Could be both. I could be also a single statement that creates a temporary files are maps it to memory. I haven’t really thought about the right syntax to use.

In C `mmap()` is a kind of extension of `malloc()`, as it can even be used to allocate regular memory without any backing file, as `malloc()` does. So it looked natural to me to include this feature in `allocate()` (but again I’m not talking about the syntax, just about the principle).

> [@ivanpribec](#):
>
> Pointer arrays, and subroutines are both _native_ elements of Fortran. Something like this could surely find a home in the [Fortran stdlib](https://github.com/fortran-lang/stdlib).

You’re right, implementing it in stdlib first is probably the right thing to do (although it will address only pointers, not allocatables, but that’s OK).

> [@ivanpribec](#):
>
> I’d also expect you’d have to change at least a second line:
> 
> ```auto
> if (enough_ram) free(arr) else munmap(arr,...);
> 
> ```

Generally speaking, sure. In our particular case it was useless as the array was needed until the very end of the execution, and the temporary file was automatically removed at the end of the execution.

---

<div class="post-metadata">

**Author:** ![JohnCampbell](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@JohnCampbell](https://fortran-lang.discourse.group/u/JohnCampbell)\
**Post date:** [January 17, 2024, 11:50am UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/9 "2024-01-17T11:50:29Z")

</div>

Memory mapped files can be created using access=‘stream’, which gives byte addressing.

But why have the data in a file ?  
Create a derived type structure with allocatable components and then most file data structures can be replicated in memory.  
Just buy enough memory for the project. Now it is a very big database that can’t fit into memory.

Now with OpenMP, the strategy is managing cache, so memory is used for data structures as disk files once were. Data structures can also be more flexible as the analysis proceeds and data components can be re-allocated.

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [January 17, 2024, 12:53pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/10 "2024-01-17T12:53:45Z")

</div>

> [@JohnCampbell](#):
>
> Memory mapped files can be created using access=‘stream’, which gives byte addressing.

Opening a file in `stream` access doesn’t mean it’s memory mapped at all (?)

> [@JohnCampbell](#):
>
> Just buy enough memory for the project.

Thanks for the tip 🙂 ! But it’s not always that simple…

---

<div class="post-metadata">

**Author:** ![nja](https://avatars.discourse-cdn.com/v4/letter/n/ed8c4c/32.png) [@nja](https://fortran-lang.discourse.group/u/nja)\
**Post date:** [January 17, 2024, 1:59pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/11 "2024-01-17T13:59:23Z")

</div>

> [@JohnCampbell](#):
>
> Just buy enough memory for the project.

It’s not only about _amount_ of memory, it’s also about _sharing_ memory between processes (not necessarily a large amount).

---

<div class="post-metadata">

**Author:** ![msz59](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@msz59](https://fortran-lang.discourse.group/u/msz59)\
**Post date:** [January 17, 2024, 2:08pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/12 "2024-01-17T14:08:53Z")

</div>

> [@PierU](#):
>
> > [@JohnCampbell](#):
> >
> > Memory mapped files can be created using access=‘stream’, which gives byte addressing.
> 
> Opening a file in `stream` access doesn’t mean it’s memory mapped at all (?)

It is _sort-of_ memory-mapped, in a sense that you can read/write at any point of the file, using `pos=` specifier, bit **it is not** in the full sense of `mmap` in C, which gives you ability to use the file as an array.

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [January 17, 2024, 9:51pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/13 "2024-01-17T21:51:58Z")

</div>

> [@ivanpribec](#):
>
> I played with this briefly in the past, using the C route. My motivation were memory-mapped arrays following this paper:
> 
> > Rojc, B., & Depolli, M. (2021). A Resizable C++ Container using Virtual Memory. In _ICSOFT_ (pp. 481-488).  
> > [https://www.scitepress.org/Papers/2021/105571/105571.pdf](https://www.scitepress.org/Papers/2021/105571/105571.pdf)
> 
> My experiment can be found here: [Virtual memory array in Fortran based on POSIX system headers · GitHub](https://gist.github.com/ivan-pi/6097d71bb1512b967008c0362f6f40cc). I admit I didn’t fully read the documentation for [mmap](https://man7.org/linux/man-pages/man2/mmap.2.html) and just blindly followed the article. I copied the parameter values out of `mman.h` header file on my Mac.

I see that you are using `MAP_PRIVATE | MAP_ANONYMOUS`. According to [this answer on SO](https://stackoverflow.com/a/39945292/14778592) (which is not plain accurate on all points, though), this is a combination that allocates a virtual memory volume, without any backing file, and the interesting point is that on Linux `malloc()` precisely uses `mmap()` with this combination for allocations above 128kBi.

Some `MAP_xxx` flags are also unclear to me.

- It seems that with `MAP_PRIVATE` (without MAP\_ANONYMOUS) it’s possible to specify a backing file, but nothing is actually written (backed) in it, so I don’t get the point of specifying a file…
- “true” memory mapping of physical files requires `MAP_SHARED`
  - I’ve then experienced that `MAP_NORESERVE` was required if the size of the mapping was exceeding the RAM+swap size.
  - `MAP_NORESERVE` is a Linux extension, and my understanding is that when used, `mmap()` does not check that the requested volume can fit in the RAM+swap… But I but don’t get why some swap space is needed at all when a physical file is present for backing the memory pages.

- There’s also `MAP_POPULATE`, and my understanding is that it is equivalent to touching all the pages
- And finally, I don’t know how to use `mmap()` for inter-proces communication 😅

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [February 3, 2024, 11:26pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/14 "2024-02-03T23:26:28Z")

</div>

> [@ivanpribec](#):
>
> My experiment can be found here: [Virtual memory array in Fortran based on POSIX system headers · GitHub](https://gist.github.com/ivan-pi/6097d71bb1512b967008c0362f6f40cc). I admit I didn’t fully read the documentation for [mmap](https://man7.org/linux/man-pages/man2/mmap.2.html) and just blindly followed the article. I copied the parameter values out of `mman.h` header file on my Mac

I have a related question that is more general: are these parameter values (such as `MAP_SHARED`, etc…) specified by the Posix standard, or do they possibly depend on the compiler?

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [February 4, 2024, 1:02pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/15 "2024-02-04T13:02:04Z")

</div>

Here’s what I have on my systems:

On Ubuntu in `/usr/include/x86_64-linux-gnu/bits/mman-linux.h`:

```cpp
#define MAP_SHARED	0x01 /* Share changes. */
#define MAP_PRIVATE	0x02 /* Changes are private. */
#ifdef __USE_MISC
# define MAP_SHARED_VALIDATE	0x03	/* Share changes and validate
					   extension flags. */
# define MAP_TYPE	0x0f /* Mask for type of mapping. */
#endif

/* Other flags. */
#define MAP_FIXED	0x10 /* Interpret addr exactly. */
#ifdef __USE_MISC
# define MAP_FILE	0
# ifdef __MAP_ANONYMOUS
# define MAP_ANONYMOUS	__MAP_ANONYMOUS	/* Don't use a file. */
# else
# define MAP_ANONYMOUS	0x20 /* Don't use a file. */
# endif
# define MAP_ANON	MAP_ANONYMOUS
/* When MAP_HUGETLB is set bits [26:31] encode the log2 of the huge page size. */
# define MAP_HUGE_SHIFT	26
# define MAP_HUGE_MASK	0x3f
#endif

```

On Darwin in `/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include/sys/mman.h`:

```cpp
/*
 * Flags contain sharing type and options.
 * Sharing types; choose one.
 */
#define MAP_SHARED 0x0001 /* [MF|SHM] share changes */
#define MAP_PRIVATE 0x0002 /* [MF|SHM] changes are private */
#if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)
#define MAP_COPY MAP_PRIVATE /* Obsolete */
#endif /* (!_POSIX_C_SOURCE || _DARWIN_C_SOURCE) */

/*
 * Other flags
 */
#define MAP_FIXED 0x0010 /* [MF|SHM] interpret addr exactly */
#if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)
#define MAP_RENAME 0x0020 /* Sun: rename private pages to file */
#define MAP_NORESERVE 0x0040 /* Sun: don't reserve needed swap area */
#define MAP_RESERVED0080 0x0080 /* previously unimplemented MAP_INHERIT */
#define MAP_NOEXTEND 0x0100 /* for MAP_FILE, don't change file size */
#define MAP_HASSEMAPHORE 0x0200 /* region may contain semaphores */
#define MAP_NOCACHE 0x0400 /* don't cache pages for this mapping */
#define MAP_JIT 0x0800 /* Allocate a region that will be used for JIT purposes */

```

To find the system mmap header, I used the file:

```auto
// find_mman.c
#include <sys/mman.h>

```

which I compiled with `gcc -H -c find_mman.c` to find the paths of the included headers.

Note I truncated the file output.

> [@PierU](#):
>
> are these parameter values (such as `MAP_SHARED`, etc…) specified by the Posix standard, or do they possibly depend on the compiler?

I haven’t checked the Posix standard, but I assume the values of the constants are system-dependent.

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [February 4, 2024, 1:10pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/16 "2024-02-04T13:10:16Z")

</div>

An easy way to get them is as follows:

```auto
// export_mman.c
#include <stdio.h>
#include <sys/mman.h>

int main(void)
{
    printf("integer(c_int), parameter :: MAP_SHARED = %d\n", MAP_SHARED);
    printf("integer(c_int), parameter :: MAP_PRIVATE = %d\n", MAP_PRIVATE);
    return 0;
}

```

```txt
$ gcc-13 export_mman.c && ./a.out > "mman.fi"
$ cat mman.fi 
integer(c_int), parameter :: MAP_SHARED = 1
integer(c_int), parameter :: MAP_PRIVATE = 2

```

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [February 5, 2024, 10:56am UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/17 "2024-02-05T10:56:01Z")

</div>

> [@ivanpribec](#):
>
> I haven’t checked the Posix standard, but I assume the values of the constants are system-dependent.

I couldn’t find any mandated values for the constants either. This means that in such cases we need some C code one way or another.

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [February 8, 2024, 10:09pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/18 "2024-02-08T22:09:43Z")

</div>

A demo code with a simplified Fortran interface: [GitHub - PierUgit/fmmap: Memory Mapped files in Fortran](https://github.com/PierUgit/fmmap/tree/main)

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [March 12, 2024, 5:19pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/19 "2024-03-12T17:19:19Z")

</div>

The demo code now runs on Windows as well (the system calls for the memory mapped files are different from the posix ones): [GitHub - PierUgit/fmmap: Memory Mapped files in Fortran](https://github.com/PierUgit/fmmap/tree/main)

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [April 9, 2024, 12:08pm UTC](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178/20 "2024-04-09T12:08:08Z")

</div>

I have now a version that is more or less stable. I am interested in any feedback about the features, the interface… Do not hesitate to open issues or answer here. [GitHub - PierUgit/fmmap: Memory Mapped files in Fortran](https://github.com/PierUgit/fmmap)

[Next page](https://fortran-lang.discourse.group/t/memory-mapped-files-in-fortran/7178.md?page=2)