Phobos addition formal review: std.experimental.allocator

[Alex Parrill via Digitalmars-d]

On Friday, 26 June 2015 at 14:56:21 UTC, Dmitry Olshansky wrote:
> On 26-Jun-2015 17:51, Alex Parrill wrote:
>> The Windows MMap allocator only keeps one HANDLE around, and 
>> creates a
>> new one on each `allocate`. Thus, `deallocate` closes the 
>> latest handle,
>> regardless of what it was actually passed, so it leaks.
>>
>
> Actually I don't see why Windows couldnt' just use VirtualAlloc 
> w/o messing with files.

Yea, VirtualAlloc seems like a better fit. (I don't actually know 
the windows API that well)

>> If I'm reading the docs for `CreateFileMapping` right, you 
>> should be
>> able to close the handle after calling `MapViewOfFile`; the 
>> internal
>> data will persist until you unmap the memory region.
>
> IIRC no you can't. I'd need to double check that though.

Here's the paragraph I'm reading:

Mapped views of a file mapping object maintain internal 
references to the object, and a file mapping object does not 
close until all references to it are released. Therefore, to 
fully close a file mapping object, an application must unmap all 
mapped views of the file mapping object by calling 
UnmapViewOfFile and close the file mapping object handle by 
calling CloseHandle. These functions can be called in any order.