<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
(truncated..)<BR><BR><BR><BR><BR><BR><BR>
<HR id=stopSpelling>
From: jay.krell@cornell.edu<BR>To: dabenavidesd@yahoo.es; m3devel@elegosoft.com<BR>Subject: RE: out of memory philosophy<BR>Date: Thu, 5 Feb 2009 18:29:59 +0000<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
Here are some ideas that contribute to handling out of memory being useful/good:<BR> <BR> <BR>"stress"<BR><BR>Stress a system.<BR>Things start going slow and failing, ok. You can't succeed against<BR>all odds, you can only try.<BR>Remove the stress.<BR>System should go back to normal, as if the stress was never applied.<BR>System should not require reboot, should not have leaked, etc.<BR><BR> <BR>(I see a lot of "leaks in error paths" in traditional code<BR>that tries lamely to be right:<BR> p = malloc(); <BR> q = malloc(); <BR> if (q == NULL) <BR> return error; /* p leaked */<BR> )<BR> <BR> <BR>"running at the edge of resource exhaustion"<BR><BR>A system is "dedicated" to a certain task.<BR>It should make the most use of the resources it has.<BR>That is, it should use all the memory and/or cpu available.<BR>Diskspace is a different matter -- so much of it generally, hard to exhaust,<BR>and hard to consume more than one resource.<BR>Using it all means it will occasionally go too far,<BR>which should gracefully fail and use a little less.<BR>If you don't aim to use it all, you won't, and you will under-utilize.<BR> <BR> <BR>You could perhaps modify this and say "aim for 90% utilization".<BR> <BR><BR>Certain "applications" might not strive to be this way,<BR>but if "the system" is not, then no application can be.<BR>The whole can only be as good as all the parts, etc.<BR>One bad apple spoils the bunch, etc.<BR>(Possible cultural-ism there.)<BR> <BR> <BR>Another approach though is to kill processes that are low on resources.<BR>Assuming that important state is managed well, like in a transactional database.<BR>And that most state is expendable.<BR>As well, resource hungry processes might be "run away" and/or "malicious".<BR> <BR> <BR>Trick of course is to discern the "important non-malicious" from the "run away"/<BR>"malicious", as well as insulating "important" server processes (daemons)<BR>from run away/malicious clients. Guard against "denial of service attacks".<BR>Some people like to put hard limits on things.<BR> "I will reject any strings longer than 2gig".<BR>However that has the affect of imposing arbitrary capacity limits where<BR> larger capacity might just work and there might be legitimate clients for it.<BR>Lately I'm using Windows findstr against text files with very long lines.<BR> It fails, it says "line too long". Darn.<BR> <BR><BR> - Jay<BR><BR><BR>
<HR id=EC_stopSpelling>
<BR>Date: Thu, 5 Feb 2009 09:56:06 -0800<BR>From: dabenavidesd@yahoo.es<BR>To: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] elminating pthread_attr_t from cloned headers<BR><BR><BR>
<TABLE cellSpacing=0 cellPadding=0 border=0>
<TBODY>
<TR>
<TD vAlign=top>Hi all;<BR>I guess there was a 1995 try to change that Runtime error into an exception (not sure if they succeed). Take a look at:<BR>ftp://ftp.u-aizu.ac.jp/pub/lang/Modula/m3/pkg/contrib/whenNEWfails/src/<BR>Please be patient if the files don't appear when loading the web page (I tried 2 times to open that url with the source files). Hope this helps.<BR>Thanks<BR><BR>--- El <B>mié, 4/2/09, Mika Nystrom <I><mika@async.caltech.edu></I></B> escribió:<BR>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px">De: Mika Nystrom <mika@async.caltech.edu><BR>Asunto: Re: [M3devel] elminating pthread_attr_t from cloned headers<BR>Para: "Jay" <jay.krell@cornell.edu><BR>CC: m3devel@elegosoft.com<BR>Fecha: miércoles, 4 febrero, 2009 11:33<BR><BR><PRE>Jay writes:<BR>...<BR>>I'll maybe review more code along these lines.<BR>>I gather the general gist of things in Modula-3 though<BR>>is that out of memory is fatal anyway. Raising an exception<BR>>vs. failing an assertion probably not significantly different<BR>>if the exception is not meant to be caught and isn't ever caught.<BR>>(Strange though then the gymnastics I pointed out elsewhere<BR>>converting one form of out
of memory to another form..)<BR>...<BR><BR>Back in SRC days I remember there was a discussion at some length<BR>about what to do in case of running out of memory. I think the<BR>project was abandoned as people realized it was quite a tricky<BR>problem...<BR><BR>I don't believe PM3 has out of memory exceptions, nor did SRC<BR>M3...? It's a wild guess but maybe this has something to do with<BR>the Critical Mass modifications for their JVM?<BR><BR> Mika<BR></PRE></BLOCKQUOTE></TD></TR></TBODY></TABLE><BR></body>
</html>