Added MmapOptions::no_reserve method

[flier]

Added MmapOptions::no_reserve method to support not to reserve swap space for this mapping. Linux only.

[flier]

I'd also like to add support for windows, but its API is not designed to be completely transparent, need use VirtualAlloc to commit the pages, it may need commit the view before use it, any suggestions?

Creating a shared memory block that can grow in size

[RazrFalcon]

any suggestions?

I have zero expertise about VirtualAlloc and winapi in general. But I would suggest calling commit implicitly.

[flier]

any suggestions?

I have zero expertise about VirtualAlloc and winapi in general. But I would suggest calling commit implicitly.

Ok, I guess we need introduce a new Index layer 0c6cd0e to calling commit implicitly.

[adamreichold]

I think for feature parity, it would suffice to just commit the whole range during creation on Windows, not lazily during access. This will avoid all the abstractions and indirections into during dereferencing.

[flier]

I think for feature parity, it would suffice to just commit the whole range during creation on Windows, not lazily during access. This will avoid all the abstractions and indirections into during dereferencing.

Agreed, for most scenarios it's possible to commit all memory at creation time.

However, for some special scenarios, such as the need for a huge sparse array or the need to be able to scale the memory size at runtime, it is not possible to predict exactly how much memory will be needed at creation time.

[adamreichold]

But since this crate is a portable layer as much as possible, we do not need to support everything the underlying OS do. We can choose a sane common denominator and since we canot avoid increasing the complexity of this crate significantly if we interpret no_reserve to always apply to whole mapping, I think we can relegate these special cases to using the underlying OS API directly.

[flier]

But since this crate is a portable layer as much as possible, we do not need to support everything the underlying OS do. We can choose a sane common denominator and since we canot avoid increasing the complexity of this crate significantly if we interpret no_reserve to always apply to whole mapping, I think we can relegate these special cases to using the underlying OS API directly.

That's why my 9326e4e commit just add a Mmap::commit method for the no_reserve case.

It's okay. If you don't like the feature, I can close the PR.

[adamreichold]

It's okay. If you don't like the feature, I can close the PR.

I did not say that. I dislike the additional complexity introduced by the third commit. Either requiring explicit action by the caller or implicit commit upon creation are fine in my opinion.