fmmap aims to provide fast file I/O base on the memory map.
The design of this crate is inspired by Dgraph's mmap file implementation in Stretto.
All the file-backed memory map has the potential for Undefined Behavior (UB) if the underlying file is subsequently modified (e.g. the file is deleted by another process), in or out of the process, this crate tries to avoid this situation by providing file lock APIs.
This crate supports std and popular async runtime(tokio, async-std, smol), and thanks to macro in Rust, it is super easy to support any new async runtime. For details, please see the implementation for tokio, async-std, smol of the source code.
The async support isn't really async. Using your async types to read a memory mapped file is not going to yield to the runtime and will block the thread just like if you read the file with blocking IO.
Can you please mark the open functions as unsafe? File locking is far from reliable. By the way are you using advisory or mandatory locks? I can't find the actual locking implementation through several layers of indirection.
Does it make sure to catch any exceptions thrown from functions called by the code running in native client then? And then handroll a longjmp implementation to jump over this code. (the real longjmp on Windows uses SEH, so the hand rolled version has to save and restore registers like on Unix)
For async types, if you want to use unblocking read or write, you should call reader, ranger_reader, writer, range_writer to get an async reader/writer. The basic read/write util functions in AsyncMmapFileExt/AsyncMmapFileMutExt is not unblocking.