Re: [Haskell-cafe] Concurrency question
I believe you're just observing lazy evaluation at work. The IO computation that you're forking is (return $ resolve cnf). `resolve` is a pure function. Hence the forked computation succeeds immediately--and the thread terminates (successfully)--without evaluating (resolve cnf). It isn't until the case arm that begins "Just (ans, stats) ->" that the result of (resolve cnf) is demanded and hence evaluation of (resolve cnf) begins. But this is too late for the timeout to have the intended effect. How to fix? You need to demand (enough of) the result of (resolve cnf) before returning from the IO computation. What "enough of" means depends on how `resolve` is written. You may find the DeepSeq module I wrote (see http://www.mail-archive.com/haskell@haskell.org/msg15819.html) helpful. Dean I've just tried DeepSeq as you proposed. >timeout :: DeepSeq a => Int -> IO a -> IO (Maybe a) >timeout n t = do res <- par_io timer thr --timer > return res >where thr = do res <- t > return $!! Just res > timer = do threadDelay n > return Nothing All works perfectly now! From now I'll pay more attention to evaluation order. Thank you for your help and attention. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thread pool in GHC
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > >To: haskell-cafe@haskell.org > >Subject: [Haskell-cafe] Re: Thread pool in GHC > >Date: Thu, 4 Aug 2005 16:47:56 + (UTC) > > > >Dinh Tien Tuan Anh 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 > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to debug GHC
On Mon, 2005-09-05 at 11:12 +0100, Malcolm Wallace wrote: > > Why is this a Cabal issue? Are you interested in adding Buddah > > support to Cabal? > > I think what Bernie is referring to is that ghc-pkg-6.4 uses an input > file format very similar to Cabal's file format, for registering a > new package. I would guess that Buddha needs to register a "buddha" > package with ghc, but for now doesn't have the right syntax. The file > formats of Cabal and ghc-pkg are so similar that many people think > they are the same thing, hence he can be forgiven for referring to > it as a Cabal issue, rather than a ghc-pkg issue. Malcolm is right. I have a ghc-pkg problem, not a cabal one. I was looking in the wrong place (cabal docs), when I should have been looking in the ghc docs. Thanks Malcolm. Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Thread pool in GHC
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 <[EMAIL PROTECTED]> To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Re: Thread pool in GHC Date: Thu, 4 Aug 2005 16:47:56 + (UTC) Dinh Tien Tuan Anh 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hat support in Cabal (was: How to debug GHC)
Malcolm Wallace <[EMAIL PROTECTED]> writes: > Isaac Jones <[EMAIL PROTECTED]> writes: > >> >> 1. Hat requires users to restrict themselves to a certain small subset >> >> of the standard libraries, and to use hmake >> > >> >Also the issue of how libraries are >> > distributed in Haskell is a little bit in flux at the moment, since >> > Cabal is still being polished. >> >> This doesn't really have anything to do with Cabal as far as I know. >> Hat comes with pre-translated libraries for a subset of the GHC >> libraries. It's true that the libraries that come with the compilers >> may change in the future, partly due to Cabal, but I don't think this >> is the reason that Hat doesn't come with all the libraries. Hat >> doesn't even use Cabal, AFAIK, but hmake. > > Well, the hope is that, eventually, Hat should be able to take any > Cabal-ised library and transparently build it for tracing. Or maybe > it will be Cabal that will support building for tracing as one "way" > amongst others (profiling, etc). In any case, the point is that Hat > pre-dates Cabal and so has no support for it, that Cabal is still > under development, and that eventually there should be a good story > for using Cabal+Hat together, but it isn't there right now. I think the later is the way to go, add a "way" to cabal to build hat-enabled libraries. Cabal has all the information, the list of source files, extensions, which compiler you're building for (does that matter to hat?). This would be a great feature to add to Cabal :) But we don't really yet have a way to build a set of libraries in a particular "way". It's _less_ painful now to build profiling libraries, but you still have to go through and build each one. Maybe cabal-get can help with that. One problem for GHC is that ghc-pkg doesn't have any sense of "way" afaik... if I build package A without profiling support, and package B depends on package A, cabal's configure stage for package B can't detect whether or not A is built with profiling support... well, maybe it could go look for the profiling libraries or something. We might have a similar problem w/ hat-enabled libraries, and maybe slightly worse... I know that GHC profiling libraries can live alongside non-profiling versions; if you build package B with profiling, GHC just looks for the right version of package A's library in a standard place. But for Hat, I'd guess we want to keep a separate hierarchy for Hat-enabled libraries, maybe even a different package database (hmmm!). In fact, that's probably what should happen for profiling and any other "way" which requires that all packages be built the same "way". peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [beta] cabal-get: install haskell packages automatically
Bulat Ziganshin <[EMAIL PROTECTED]> writes: > Hello Isaac, > > Monday, September 05, 2005, 12:16:46 AM, you wrote: > > IJ> We're looking for beta testers to try out "cabal-get" (for downloading > IJ> and installing) and "cabal-put" (for uploading to the central > IJ> repository). We're also looking for more developers to work on this. > > can i ask for some more abilities? specifically, about web interface > to package/applications database We already have this, under the "view" link. > and ability to include in this database other things related to > Haskell, such as papers and peoples? That would be pretty interesting... we're not really set up for anything like this yet; the wiki could be used for some of this. I think Shae (cc'd) is working on something for papers. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [beta] cabal-get: install haskell packages automatically
Hello Isaac, Monday, September 05, 2005, 12:16:46 AM, you wrote: IJ> We're looking for beta testers to try out "cabal-get" (for downloading IJ> and installing) and "cabal-put" (for uploading to the central IJ> repository). We're also looking for more developers to work on this. can i ask for some more abilities? specifically, about web interface to package/applications database and ability to include in this database other things related to Haskell, such as papers and peoples? imho, ultimate goal of such project will be CPAN-like environment, with ability to download, upload and search, so that "Haskell activity report" will be no more needed -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to debug GHC
Isaac Jones <[EMAIL PROTECTED]> writes: > >> 1. Hat requires users to restrict themselves to a certain small subset > >> of the standard libraries, and to use hmake > > > >Also the issue of how libraries are > > distributed in Haskell is a little bit in flux at the moment, since > > Cabal is still being polished. > > This doesn't really have anything to do with Cabal as far as I know. > Hat comes with pre-translated libraries for a subset of the GHC > libraries. It's true that the libraries that come with the compilers > may change in the future, partly due to Cabal, but I don't think this > is the reason that Hat doesn't come with all the libraries. Hat > doesn't even use Cabal, AFAIK, but hmake. Well, the hope is that, eventually, Hat should be able to take any Cabal-ised library and transparently build it for tracing. Or maybe it will be Cabal that will support building for tracing as one "way" amongst others (profiling, etc). In any case, the point is that Hat pre-dates Cabal and so has no support for it, that Cabal is still under development, and that eventually there should be a good story for using Cabal+Hat together, but it isn't there right now. > >> 2. Buddha doesn't work with GHC 6.4 > > > > True. This is a cabal issue, that I haven't had time to resolve. buddha > > is limited to even fewer libraries than Hat. > > Why is this a Cabal issue? Are you interested in adding Buddah > support to Cabal? I think what Bernie is referring to is that ghc-pkg-6.4 uses an input file format very similar to Cabal's file format, for registering a new package. I would guess that Buddha needs to register a "buddha" package with ghc, but for now doesn't have the right syntax. The file formats of Cabal and ghc-pkg are so similar that many people think they are the same thing, hence he can be forgiven for referring to it as a Cabal issue, rather than a ghc-pkg issue. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
