[darcs-users] Re: /proc/.../maps results

[Peter Strand]

David Roundy wrote:
> It's reasonable if the garbage collector hasn't run recently.  Darcs only
> unmaps files on GC, and when a file gets modified, darcs creates a new
> inode and then (when it wants to read the modified version) mmaps the file
> again.
> 
> It may be that we should trigger the GC manually to ensure that mmapped
> files are released in a timely manner, but on the other hand, we don't want
> to waste time garbage collecting if we can avoid it.

I think the possibility to use a function like

withMappedFile :: FileName -> (FileContents -> IO ()) -> IO ()
(or something similar)

should be considered as well, to get exact control of resource usage.
Sadly, it doesn't fit at all with how darcs currently treats slurpies,
from what I have seen.
The use of unsafeInterleaveIO, to get pure and lazy reading of files is
nice, but it does have its share of drawbacks as well.

As a compromise, we could manually keep track of mapped files, and close 
them between rounds of modifications (patch applications, in the get
case?), like the AtExit stuff but not necessarily at exit.

Deterministic mapping of files would also make it possible to use mmap
on windows, i believe. Last time I looked, too long-lived mappings was
the showstopper there.



/Peter