[MLton-devel] very unfortunate behavior when profiling allocations
Henry Cejtin
henry@sourcelight.com
Tue, 1 Jul 2003 20:52:26 -0500
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