[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 leaves thunks unevaluated. 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 Anton van
Straaten
Sent: Thursday, 7 May 2009 4:28 PM
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Is Haskell a Good Choice for Web
Applications?(ANN: Vocabulink)

FFT wrote:
> On Wed, May 6, 2009 at 8:20 PM, Anton van Straaten 
> <anton at appsolutions.com> 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)

Haskell lets you easily create "infinite" lists, which is a powerful and
useful feature.  But if you abuse that feature, you'll have problems,
because you don't have infinite memory.  The further you traverse an
infinite list, while maintaining a reference to its head, the more
memory you use.  It'd be a stretch to characterize this as "hard".

I don't see much connection between this and the space efficiency of
long-running programs.

I feel a bit like we're discussing a monster under the bed: "i bet it's
huge! its teeth must be so sharp!"  Maybe we should just look under the
bed, i.e. implement what we need and see what happens?

Anton

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe