Jason Dagit wrote:
I know from experience that lambdabot tends to be leaky. Otherwise,
lambdabot wouldn't be running on my server to begin with. And, even
so, Cale monitors lambdabot to make sure it is not using too many
resources (and I complain when/if I notice it). I have heard similar
stories related to hpaste and happs.
FWIW, I have an internal HAppS application that's been running
continuously since November last year, used daily, with stable memory usage.
I have also experienced it with
writing a forever loop in Haskell that did polling from channels. I
would leave my app running for, say, 4 hours and it would be using
tons of memory.
If you posted an example of that, there are probably people who'd be
interested in debugging it.
I think it's fair to say that keeping the memory usage low of a long
running Haskell app is hard, but that is a general issue not just a
Haskell issue. It's hard in most languages.
I don't agree with this. This should not be hard in language
implementations with good garbage collectors, that don't have known
limitations (this excludes e.g. conservative GC and reference-counting
systems). In my experience, it's not hard to write stable long-running
code in good implementations of languages like Haskell, Scheme, Common
Lisp, or Java.
I think what we need to
address this is more information about preventative measures. What
programming styles cause the problem and which ones solve it. I would
say that I lack confidence recommending anyone to use Haskell for long
running processes because I don't understand well the problem of
keeping the usage low. If it is a well documented problem with
documented solutions (more than just profiling), then I would regain
my confidence because I know the problem can be worked around
reliably. Does this make sense? Maybe it's already well documented?
This doesn't completely make sense to me, in that either a program has a
space leak, or it doesn't. If it does, you debug it and resolve it. If
a leak really is due to a problem with the language implementation or
standard libraries, then that should be identified and reported. There
shouldn't be any deep mystery here. At the very least, it should be
possible to point to the relevant trac tickets if there really is a problem.
Anton
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
