Memory Mapped File Access

[Andrei Alexandrescu]

On 05/29/2010 02:52 PM, Robert wrote:
> On 2010-05-29 18:30:13 +0200, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> said:
>
>>> Andrei and I had talked a while back about adding memory-mapped file
>>> support to the GC and then it fell off the radar while we worked on
>>> other things. I'll see if I can remember how it was to work.
>>
>> The basic idea is that the only way to handle memory-mapped files
>> safely is to let the garbage collector close them. This is because in
>> any other case you'd have dangling pointers.
>
> Ok, that makes sense. On the other hand I will use a very simple
> rule-of-thumb: As long as the app runs the file is open. Only if the app
> terminates the file gets closed.

That might be the case if no collection ensues, but if a collection 
does, the runtime should attempt to reclaim available resources.

> Which implies that the reference to the MMF is a global but this
> shouldn't be a problem.
>
>> So the idea is that druntime should provide a safe means for mapping a
>> file to memory and an unsafe means of closing a file.
>
> Why should it provide an unsafe way of closing a MMF file?

For applications concerned with deterministic closing of a file (e.g. 
following writing) and that are willing to take the unsafety risk.

>> Safe code should be able to count on the garbage collector to close
>> memory-mapped files that have no pointers referring to them.
>
> Have you sketched any ideas how to use the GC for MMF?

There's nothing to sketch, really. The runtime tracks the opened 
memory-mapped files and the memory ranges associated with them. Upon a 
collections, if a file's memory has been successfully freed, the file 
can be safely closed.


Andrei



Andrei