[MLton-devel] very unfortunate behavior when profiling allocations

[Henry Cejtin]

I point out that Norman's problem is really an indication that we are missing
something.  In the case of the  profile  writing  code  I  would  guess  that
converting  it  to C isn't a huge deal, but in general there will come things
where this is not the case.  One example  I  have  mentioned  before  is  the
creation  of  temporary  files.   If the program runs out of memory then they
will not be cleaned up.

My notion before, which I would think would still be good, would be to simply
make  out-of-memory  be an exception.  The notion is that when you get to the
first handler, you get to GC what was alive before but isn't now.   If  there
isn't enough memory for the handler then the exception would be raised in it,
etc.

I know that Stephen  objected  because  the  exceptions  are  now  some  what
asynchronous,   but  I  don't  think  that  is  really  a  problem.   A  more
conservative extension would be to have a ML atExit which would be  the  only
handler  to try the above.  A problem with this is that you often, in C, know
and depend on the fact that the atExit code is NOT run if you abort.

The kind of thing I am also thinking of is something like an  editor  written
in ML.  You cannot exit if you run out of memory.  Of course the handlers are
going to have to do something to free up some space, but the notion  of  some
stack  frames  now  being dead would seem to me to be sufficient to make this
kind of thing work.



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel