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

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@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Anton van Straaten Sent: Thursday, 7 May 2009 4:28 PM To: haskell-cafe@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 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe