I think it would go back to the pool. The finally clause means that even if the thread dies from an exception (which, AFAIK, is how kills are modelled), the thread count would be restored. Gen On 9/6/05, Dinh Tien Tuan Anh <tuananhbirm@hotmail.com> wrote:
Its probably too long to bring back this topic, but i have a small question.
If some threads may never terminate and have to be killed by killThread, are they going back to the pool, or we need some twist to force them.
Thanks a lot TuanAnh
From: genneth <genneth@gmail.com> To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Re: Thread pool in GHC Date: Thu, 4 Aug 2005 16:47:56 +0000 (UTC)
Dinh Tien Tuan Anh <tuananhbirm <at> hotmail.com> writes:
Can thread pool be implemented in GHC ?
I have a program that is currently using about 12-15 threads (launch and kill for infinite times) and when running, especially after Ctrl-C, my computer got freezed up. And if i ran it several times, the "Stack overflows" occurs.
I made the following a while back. Maybe it's useful...
limitedThreadsWithChannelMapM :: Integer -> (a -> IO b) -> [a] -> IO [MVar b] limitedThreadsWithChannelMapM lim ioaction x = do threadpoolcounter <- atomically ( newTVar 0 ) mapM (throttledFork threadpoolcounter . ioaction) x where throttledFork poolcount io = do atomically ( do prev <- readTVar poolcount if prev >= lim then retry else writeTVar poolcount (prev+1) ) mvar <- newEmptyMVar forkIO( finally (io >>= putMVar mvar) (atomically ( readTVar poolcount >>= writeTVar poolcount . (subtract 1) ) ) ) return mvar
Cheers TuanAnh
_________________________________________________________________ Winks & nudges are here - download MSN Messenger 7.0 today! http://messenger.msn.co.uk
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_________________________________________________________________ Winks & nudges are here - download MSN Messenger 7.0 today! http://messenger.msn.co.uk