Actually, I'm unsure how to fix this. For an expression like this: Data.Map.delete key map how can I use seq (or something else) to sufficiently evaluate the above to ensure that the value associated with key can be garbage collected? My knowledge of Data.Map is limited to it's haddock documentation. -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Tim Docker Sent: Thursday, 7 May 2009 6:04 PM To: haskell-cafe@haskell.org Subject: RE: [Haskell-cafe] Is Haskell a Good Choice for WebApplications?(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 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@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of wren ng thornton Sent: Thursday, 7 May 2009 2:06 PM To: haskell-cafe@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe