[MLton] Writing memory to disk ...

[Wesley W. Terpstra]

On May 24, 2006, at 7:49 PM, Stephen Weeks wrote:
> When the feature is enabled, it is important for MLton to choose a
> good default across platforms so that people don't have to duplicate
> the logic for this.  It is a bad idea to require the tempdir on the
> command line, because of duplication of logic, because people are
> likely to get it wrong, and because we already support overriding it
> via environment variable.

The environment variable override is fine too if it's documented  
somewhere.

The thing that worried me is that this code is enabled in every  
application I've compiled with MLton... and even as a developer I had  
no idea this would happen. If I had gotten a bug report about this  
from someone regarding a program I maintain, I would have assumed  
they were just a very confused user.

> I don't understand Wesley's claim that MLton doesn't check that the
> write to disk succeeds.  The runtime uses the write_safe call (in
> x86_64 branch lingo), which certainly checks, and fails if the write
> was not complete.  If there's a problem here, it should be fixed, but
> I don't see it.

Ahh. I presumed write_safe would return an error code, after  
attempting rewriting. Since there was no return code checked, I  
presumed it just tried to continue. However, what it does now is also  
bad in that if it *did* fill up your disk, it won't even delete the  
file afterwards. So, MLton can eat up the last bytes and then not  
release them. For my osx computer, that would be a sure-fire way to  
kill my desktop (they really ought to fix this).

>  * Disable this functionality by default.

My main concern.

>  * Add a runtime option, "disk-backed" (I'm open to other names), that
>    enables this functionality.

Please don't use 'disk-backed'---I have nothing better to suggest,  
but I only proposed that as a (terrible) example.
Whatever the choice, this should definitely be added to the  
documentation of MLton runtime parameters.

>  * Refactor as Ville suggests, moving the code to platform/*

Whole-hearted agree.
As an aside, I like the smaller more logical pieces in the x86_64  
branch. I find navigating them much easier.

>  * Change the default directory on non-Windows machines to /var/tmp.
>    Is there any other platform that should remain as /tmp or be
>    something else entirely (AIX, *BSD, Darwin, HP-UX)?

/var/tmp seems fine for osx.

I agree with Henry that as long as MLton doesn't clean up after  
itself, /var/tmp is bad for linux. However, once the write_safe  
doesn't abort and die, but deletes the failed attempt, then /var/tmp  
is preferable on linux too.