# Method to unsafely close a mmap

**URL:** https://discourse.julialang.org/t/method-to-unsafely-close-a-mmap/129900
**Category:** Internals & Design
**Tags:** mmap, io, feature-request
**Created:** [June 15, 2025, 7:25pm UTC](https://discourse.julialang.org/t/method-to-unsafely-close-a-mmap/129900 "2025-06-15T19:25:48Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![nhz2](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nhz2/32/44428_2.png) [@nhz2](https://discourse.julialang.org/u/nhz2)
#### Post date: [June 15, 2025, 7:25pm UTC](https://discourse.julialang.org/t/method-to-unsafely-close-a-mmap/129900/1 "2025-06-15T19:25:48Z")

</div>

Currently the `Mmap.mmap` function uses a [finalizer](https://github.com/JuliaLang/julia/blob/a23ce4bcbbb06be413169424cbffee0718b8a431/stdlib/Mmap/src/Mmap.jl#L256-L264) to handle calling `munmap` or `UnmapViewOfFile` when the array is garbage collected.

It is useful to be able to do this finalization eagerly despite the potential risks if there are any unexpected references. Ref:

> <https://github.com/JuliaIO/JSON.jl/pull/374#discussion_r2100720767>
>
> I think the \`ref\` field is not public.

> [@Struggling to use Mmap with ZipArchives](https://discourse.julialang.org/t/struggling-to-use-mmap-with-ziparchives/129839):
>
> I’m struggling to get ZipArchives.jl and Mmap.jl to work together in the way I want - basically just following the docs. MWE looks like this: using ZipArchives using Mmap io=open("simpletest.zip") mm=Mmap.mmap(io) q = ZipArchives.ZipReader(mm) readme\_n\_lines = zip\_openentry(q, "xl/worksheets/sheet1.xml") do z countlines(z) end close(io) #GC.gc() ZipArchives.ZipWriter("simpletest.zip") do w zip\_newfile(w, "test/test2.txt") write(w, "I am data inside test2.txt in the zip file") end…

> <https://github.com/JuliaLang/julia/pull/54210#issuecomment-2676521367>
>
> This broke TextParse.jl (and I believe CSV.jl also). Both used calls to \`finaliz…e(array)\` to deterministically release the OS resources associated with memory mapped files. Both now have workarounds, but they feel hacky as they are now depending on what is presumably internals (see e.g. https://github.com/JuliaData/CSV.jl/blob/9f95cfbd82fd0096497a26eb57998ec66758bcb6/src/file.jl#L342-L347).

Currently CSV.jl uses does the following as a workaround:

> <https://github.com/JuliaData/CSV.jl/blob/04ec1cf3a7b0f069c573ba7c9da351026427532b/src/file.jl#L342-L346>

Could a function that does this be added to the `Mmap` API as @topolarity suggested in [attach finalizer in `mmap` to the correct object by KristofferC · Pull Request #54210 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/54210#issuecomment-2676877066)

---

<div class="post-metadata">

### Author: ![TimG](https://avatars.discourse-cdn.com/v4/letter/t/82dd89/32.png) [@TimG](https://discourse.julialang.org/u/TimG)
#### Post date: [June 16, 2025, 7:41am UTC](https://discourse.julialang.org/t/method-to-unsafely-close-a-mmap/129900/2 "2025-06-16T07:41:38Z")

</div>

We already know that a well placed GC call can have the desired effect. The downside is that garbage collection is expensive and probably does (much) more than is necessary for `mmap` alone. So my naive view is that it should be possible to isolate that bit of the GC call that does the trick for `mmap` and implement that as part of the `mmap` API.
