Add support for named, non-persisted memory-mapped files

[stephentoub]

We currently don't support names for memory-mapped files. We should be able to add such such support by using POSIX shared memory objects, at least for non-persisted maps (as opposed to persisted ones, those backed by files on disk).

[stephentoub]

I'm planning to close this issue and leave the feature as not supported on Unix; simply a case where the .NET API was created based on the memory-mapped files feature set on Windows, and the memory-mapped file feature set on Unix is different. If anyone disagrees, please let me know and submit a design for how this can be done well... I've been unable to find a mechanism supported consistently on at least Linux and OSX that provide the right semantics we need and in a robust manner.

For example, when a MemoryMappedFile is created with our implementation today, we create a backing store behind it that results in a file descriptor we can use with mmap, either via shm_open or with a temporary file on disk, both of which have names (we create random ones for this purpose). To ensure that this backing store is reliably cleaned up, we need to unlink it immediately after opening it, or else if the process were to crash, the data from the map would be left in memory or on disk indefinitely (in the case of an shm_open, until restart, and in the case of a file, until tmps are cleared). But by unlinking it immediately, we remove its name from visibility, such that no one else can query for or open that same backing store by name; any attempt to would result in using a completely different backing store. If we instead leave the name available without unlinking, we run the risk of leaking data.

As another example, I created an implementation using SysV shared memory segments. On Linux, we can mark the segment for deletion (basically unlinking) such that the key-to-id mapping is removed, but if you know the ID you can still attach the memory by it's ID, enabling a semi-hacky solution whereby a file of the appropriate name is created to hold the ID; processes can lock the file to coordinate, can read the ID from the file and attempt to open it to determine if it's still valid, etc. However, this feature of having the ID still valid even after marking for deletion is described in the man pages as being non-conforming and that most other systems don't support it. Further, OSX has default limits on the size of such segments that are way too small for any practical use in this scenario (on my system, 4MB); this can be changed with admin rights, but that means that such changes would be necessary prior to running any software that uses System.IO.MemoryMappedFiles in this manner. Plus, even if we got this to work, certain other features like copy-on-write wouldn't work and we'd have to throw PlatformNotSupportedExceptions for those.

@ellismg, FYI.