[Haskell-cafe] Is Haskell a Good Choice for Web Applications?(ANN: Vocabulink)

[Tim Docker]

I think that multi-threading in combination with laziness makes space
usage harder to manage. In fact, just today
I have discovered a problem with a long running server process with a
subtle space leak.

With a regular process that communicates with the outside world via IO,
I know that the act of communicating a
value causes it to be fully evaluated. However, with a multi threaded
process, communication occurs via writes
to TVars/IOVars and nothing gets evaluated. This gives lots of
opportunities for space leaks. In this
particularly case cleanup code was removing a large entry from a map
stored in a Tvar. Because that map is only
read infrequently, however, the memory release is delayed.

This is the second such problem I've found. The profiling tools do help
in discovering them, but it still needs
a bit of thought and analysis. I wonder if, for my application, I should
work out some means of deepseqing every
value written to a Tvar.

Tim

-----Original Message-----
From: haskell-cafe-bounces at haskell.org
[mailto:haskell-cafe-bounces at haskell.org] On Behalf Of wren ng thornton
Sent: Thursday, 7 May 2009 2:06 PM
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Is Haskell a Good Choice for Web
Applications?(ANN: Vocabulink)

FFT wrote:
> Anton van Straaten wrote:
> 
> > The app is written for a client under NDA, so a blog about it would 
> > have to be annoyingly vague.
> 
> > No doubt the potential for encountering space leaks goes up as one 
> > writes less pure code, persist more things in memory, and depend on
more libraries.
> 
> Exactly. I'm worried about, e.g. needing to use something as simple as

> a stream of prime numbers (see the recent thread about leaks there)

The issues here are going to be the same in Haskell as in every other
language. There's always a tradeoff between the memory of caching old
results vs the time of recalculating them. At present no language's
RTS/GC is smart enough to make that tradeoff for you, and so memoization
must be done manually.

There are some tricks to help make this easier (e.g. weak pointers), but
the problem will always remain. The only thing that makes this perhaps
trickier than in other languages is that, AFAIK/R, the reflection API to
ask the RTS how it's feeling about memory at any given point isn't
terribly portable (between Haskell compilers) or polished/pretty. Then
again, the other GC languages I've dealt with aren't much better and are
often worse.

--
Live well,
~wren
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe