Nice! This is certainly worth it. I really liked the simplicity of the threadmanager package, it certainly was better than managing threads manually. But your concurrent-extra package seems to do a way better job, I'm certainly going to apply this patch.
Thanks a lot guys! Groet, Sebastiaan On Mar 23, 2010, at 12:36 PM, Bas van Dijk wrote: > On Sun, Mar 21, 2010 at 5:05 PM, Sebastiaan Visser <sfvis...@cs.uu.nl> wrote: >> Straight from Zurihac: I'm very pleased to announce the 1.0.0 release of the >> Salvia web server. > > Hoi Sebastiaan, > > (switching to English) I discovered a major space-leak in > Network.Salvia.Impl.Server.start due to the use of threadmanager: > > When a request handler is forked the threadmanager internally maps the > threadId to a status MVar. However when the request handler terminates > this association is not deleted from the internal Map. This results in > a major O(n) space-leak where n = the number of requests accepted. > > This space-leak can be visualized when you heap-profile the > salvia-helloworld demo: > > salvia-helloworld +RTS -hy > > and perform some requests: > > $ for ((a=0; a<10000; a++)); do curl -s -o /dev/null localhost:8080; done > > You will then get the following heap profile which will clearly > highlight the linear space-leak: > > http://bifunctor.homelinux.net/~bas/salvia-helloworld_ORIGINAL_10000_requests.ps > > I fixed it by replacing threadmanager by Control.Concurrent.Thread[1] > from Roel's and mines concurrent-extra. This module has the following > advantages over threadmanager: > > * Simpler: We don't have the concept of a ThreadManager. So you don't > need to make one and pass it to fork and wait. > > * More efficient: We don't keep an internal mapping from ThreadIds to > status MVars. > > * Correct: threadmanager has a bug where it can potentially miss the > termination of a thread. It doesn't block asynchronous exceptions > before it forks the computation that will install the necessary > exception handler before executing the given action. We correctly > block asynchronous exceptions. > > Besides these advantages we have the ability to get the return value > of the forked thread so you don't need a mutable variable. > > Besides replacing threadmanager I now manually delete the threadId of > the request handler when it terminates. > > When I repeat the heap-profile you will now see a nice constant heap-usage: > > http://bifunctor.homelinux.net/~bas/salvia-helloworld_NEW_10000_requests.ps > > I don't know how to attach my git patch to this email so I just copied > my git repository to: > > http://bifunctor.homelinux.net/~bas/salvia/ > > I think you can just pull from there. > > Groeten, > > Bas > > [1] > http://hackage.haskell.org/packages/archive/concurrent-extra/0.4/doc/html/Control-Concurrent-Thread.html _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
