Memory Mapped File Access
SeeWebsiteForEmail at erdani.org
Sat May 29 14:23:06 PDT 2010
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.
More information about the Digitalmars-d