pierugit/fmmap

Memory Mapped files in Fortran

fmmap's Issues

Adding READ/WRITE access requests

Fast creation of a large file?

Keeping the writeback feature?

writing back can be done by the user with more flexibility, so the added value of this feature is not obvious...

add topic tag memory-mapped-file

I suggest adding the topic memory-mapped-file in the About section.

Should the "FMMAP_NOFILE" option be kept?

The FMMAP_NOFILE option creates an anonymous mapping: it's just a virtual memory allocation without a specific backing file (the system swap is used if needed).

It's not different from what the intrinsic ALLOCATE() does, so the question is "should it be kept?", as it's redundant.

I basically introduced it for flexibility: the same code could perform a named or anonymous mapping depending on the needs, by just switching this option.

Windows equivalent of "MAP_NORESERVE" ?

In the posix case, the mappings are created with the MAP_NORESERVE flag. As far as I can understand it (but I'm definitely not sure to understand it), it corresponds to a lazy allocation: the pages stay virtual until we touch them.

I'm not sure what is the equivalent in the Windows case. The CreateFileMappingA() function has the following flags: SEC_COMMIT and SEC_RESERVE, but they have apparently an effect for anonymous mappings only.

Port to Windows

Posix only at the moment

Exposing the fmmap_t type instead of just the C pointer?

In the case the intrinsic types versions are removed, it could make sense to expose the (currently) internal type fmmap_t. It would suppress the management of the internal table, and one could have type bound procedure instead of classical ones.

Mapping a part of the file

and not only the whole file

Closing the file right after mapping

Currently the file remains opened until the mapping is destroyed. In principle it could be closed right after the mapping is created, on both posix and Windows (this has to be tested nonetheless).

On the other hand I can't see any obvious drawback to keep the file opened... So not a priority

Remove the intrinsic types versions?

These versions require a significant maintenance work compared to the C pointer version, for a relatively limited advantage for the user (i.e. the C pointer version is not much more difficult to use, generally just an additional call to c_f_pointer()).

Moreover, selecting which types/kind should be handled is arbitrary and difficult in the absence of any generic programming capabilities.

Therefore I plan removing these versions for the first beta release.