gh-44098: Release the GIL during mmap on Unix

[hauntsaninja]

This seems pretty straightforward. The issue mentions other calls in mmapmodule that we could release the GIL on, but those are in methods where we'd need to be careful to ensure that something sensible happens if those are called concurrently. In prior art, note that #12073 released the GIL for munmap. In a toy benchmark, I see the speedup you'd expect from doing this.

• Issue: release GIL while doing I/O operations in the mmap module #44098

Automerge-Triggered-By: GH:gvanrossum

[gvanrossum]

Might I suggest qualifying this with "on UNIX"? The Windows version is different, and I won't ask you to update it (we should leave that up to @zooba).

Otherwise seems harmless. Is this based on an actual use case?

[hauntsaninja]

Thanks, good suggestion, made the change.

This is not based on an actual use case. I was going through old issues and saw your comment asking for a patch here: #44098 (comment)
That said, I think I have some code at work that may benefit (would take some effort to figure out exactly how much though, and today's a holiday).

[miss-islington]

Status check is done, and it's a success ✅.

[vstinner]

In a toy benchmark, I see the speedup you'd expect from doing this.

Just curious: What is the benchmark? What are results?

[hauntsaninja]

Toy benchmark code:

import mmap
import time
import threading

with open("hello.txt", "wb") as f:
    f.write(b"Hello Python!\n")

with open("hello.txt", "r+b") as f:
    fn = f.fileno()

    def run_mmap():
        for _ in range(100):
            mmap.mmap(fn, 0)

    s = time.perf_counter_ns()
    run_mmap()
    e = time.perf_counter_ns()
    print((e - s) / 1e9)

    s = time.perf_counter_ns()
    threads = [threading.Thread(target=run_mmap) for _ in range(8)]
    for t in threads:
        t.start()
    for t in threads:
        t.join()
    e = time.perf_counter_ns()
    print((e - s) / 1e9)

On my laptop, the threaded portion goes from about 5-7s to 1-2s with this patch