- Glasgow-haskell-users

Re: Is it true that an exception is always terminates the thread?
by John Lato 27 Jan '12

27 Jan '12

> From: Heka Treep <zena.treep(a)gmail.com> > Subject: Re: Is it true that an exception is always terminates the > thread? > To: "Edward Z. Yang" <ezyang(a)mit.edu> > Cc: glasgow-haskell-users <glasgow-haskell-users(a)haskell.org> > Message-ID: > <CAMChDeP5mv7pu8+MbR_NZzm3vCF-3AqxY7PiOHBA8R91yWCyrQ(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > 2012/1/23, Edward Z. Yang <ezyang(a)mit.edu>: >> Excerpts from Heka Treep's message of Mon Jan 23 13:56:47 -0500 2012: >>> adding the message queue (with Chan, MVar or STM) for each process will >>> not >>> help in this kind of imitation. >> >> Why not? Instead of returning a thread ID, send the write end of a Chan >> which the thread is waiting on. You can send messages (normal or >> errors) using it. >> >> Edward >> > > Yes, one can write this: (others have commented on your actor implementation already) I'm not certain I understand your comment about synchronization; the STM implementation handles all of that. Unless you mean that you'd rather not write the "atomically"'s when writing to the TChan. But you can define: > ! :: TChan a -> a -> IO () > chan ! msg = atomically $ writeTChan chan msg This allows you to write: > test = do > mbox <- spawn actor > mbox ! "1" > mbox ! "2" > mbox ! "3" which seems to be exactly what you want. For the record, it's probably possible to do this with async exceptions, but I would not want to maintain it. For one, async exceptions are how GHC implements a lot of thread management stuff (e.g. the ThreadKilled exception). You would need to be careful that your code doesn't interfere with that. Another concern is the thread mask state, which needs to be handled carefully. For example, if you perform an "interruptable operation" while processing the message (e.g. blocking IO), another message could be received at that point, which I believe would abort processing of the first message. If you use "uninterruptableMask", then as I read the docs you can't block *at all* without making the thread unkillable. Doing this with async exceptions would be tricky to get right. STM is the best approach. John L.

5 5

Is it true that an exception is always terminates the thread?
by Heka Treep 27 Jan '12

27 Jan '12

I try to mimic Erlang like this: -------------------------------------------------------------------------------- {-# LANGUAGE FlexibleInstances #-} import Prelude hiding ( catch ) import Control.Monad import Control.Concurrent import Control.Exception spawn = forkIO wait = forever $ threadDelay (maxBound :: Int) receive = catch wait (!) = throwTo instance Exception String test = do let actor = receive putStrLn p <- spawn actor p ! "1" p ! "2" p ! "3" -- > test -- 1 -- <interactive>: "2" -------------------------------------------------------------------------------- but raise an exception terminates the thread. This is quite natural, of course. What I need is a messages -- something that works just like exceptions but don't stop a thread's computations. I mean, the scheduler knows about asynchronous exceptions, adding the message queue (with Chan, MVar or STM) for each process will not help in this kind of imitation. It's possible to solve this problem with the exceptions or with something? Or the message communication should be implemented as a new feature in the RTS?

4 7

Re: Records in Haskell
by Anthony Clayden 27 Jan '12

27 Jan '12

Ryan Newton <rrnewton <at> gmail.com> writes: > > I admit I'm a big fan of polymorphic extension. But I don't love it enough for it to impede progress! > > Regarding extension: In trying to read through all this material I don't see a lot of love for "lacks" constraints a la TRex. > Cheers, > -Ryan > Hi Ryan, I think the "lacks" constraint is sadly misunderstood, and in fact something like it will be needed eventually. [A thousand apologies for the multiposts! somewhere between gmaniac and pipermail, half my posts are going missing: I was only just warming up this far. Try again ... again ... third time] (If anybody who knows the internals of Hugs/TRex is listening, it would be great to get confirmation of the following.) As you say, it relates to whatever might happen for polymorphic records, so is outside the scope of what SPJ is trying to address in this thread. On the other hand, let's try to avoid developing an approach for 'Records in Haskell' that has to be undone when/if we get more polymorphic. >From all the suggestions in the current thread, I'm expecting the approach will include a Has class with methods get and set. It would be sweet if in future the same Has class could be extended to extended(!) records, anonymous records, renamed labels, projections on records, merged records (as you'd get from a relational join), etc. Specifically: Has r l t => ... really must mean there's exactly one field labelled l in record r, at type t (which is a constraint on whatever merged/extended term r is) compare TRex's (r\l) => ... Rec {| l : t | r |} ... which really means there's exactly one field labelled l in the Rec, at type t In hindsight, I think it was unfortunate that the original TRex paper [1] used the word "lacks" in context of its notation for constraining the record structure. (I'm looking especially at section 2.1 'Basic Operations'.) In all the operations, the types always include a Rec term with _both_ l and r. They don't all have a term of a 'bare': Rec {| r |} TRex is trying to avoid a positional specification of the record fields (which is 'implementation determined'/hidden from the programmer). But I think of 'bare' r as representing a record with a 'hole' at whatever position l is in the full record. (So the constraint (r\l) means: you're going to find a Rec with exactly one l in it; if you also find a Rec with 'bare' r, that means the same Rec, but with a 'hole'.) The HList guys picked up the word "lacks", and adapted it (successfully in context of what they were doing) to build 'Type Indexed Hlist's -- that is, record-like structures with exactly one field labelled l. Perhaps TRex should have used a notation something like: (rr :> l @ t) => Rec {| rr |} ... -- HasUnique rr l t ... Rec {| rr \ l |} ... -- rr with a hole in place of l You say: > As one anecdote, I've been very pleased using Daan Leijen's scoped labels approach My anecdote: the new approaches and extensions to type inference in GHCi have been frustratingly slow in arriving and maturing. But we now have working superclass constraints, including type equality (~), and some heavy-weight type inference. I've built a toy (and somewhat limited) polymorphic record system (with Has/get/set), which: treats Data types as records; and treats tuples as anonymous (type-indexed) records; and implements project, extend and merge. It relies on overlapping instances (so I don't mention it in polite company -- at least it doesn't use FunDeps to boot!). I achieve the effect of 'HasUnique' through instance resolution: if there's more than one occurence of label l in the record term, GHC bitches. (This is fragile: I can't use IncoherentInstances, and sometimes UndecidableInstances gives trouble.) [1] A Polymorphic Type System for Extensible Records and Variants, Gaster/Mark P. Jones, 1996.

1 0

FW: A Garbage Collection Question
by Simon Peyton-Jones 26 Jan '12

26 Jan '12

Can anyone help Burak? Simon -----Original Message----- From: burak ekici [mailto:ekcburak@hotmail.com] Sent: 24 January 2012 08:12 To: Simon Peyton-Jones Subject: A Garbage Collection Question Dear Dr. Jones, this time I am disturbing you to ask a question about how garbage collection is being managed in parallel GHC? When I use, (compositional) original strategies to parallel any part of a code, what I expect is that none of the created sparks has to be pruned, instead they should be all converted. Since, it is not possible to adopt WEAK policy in this type of strategies, due to losing the potential parallelism. (ref: Seq no more: Better Strategies for Parallel Haskell) However, in my experiments most of created sparks are getting pruned, although I use compositional strategies. Here you can see mentioned part of code, below. What could be the reason? I would be appreciated, if you shed light on the issue? Sorry for the disturbance! Kind regards, Burak. CODE: instance NFData a => NFData [a] where rnf [] = () rnf (x:xs) = rnf x `pseq` rnf xs karatsuba _ [] _ = [] karatsuba _ _ [] = [] karatsuba currentDepth xs ys | (l < 32 || currentDepth >= limit) = mul xs ys | otherwise = (x `add` (replicate l False ++ (z `add` (replicate l False ++ y)))) `Main.using` strategy where l = (min (length xs) (length ys)) `div` 2 (xs0, xs1) = splitAt l xs (ys0, ys1) = splitAt l ys x = (normalize (karatsuba (currentDepth+1) xs0 ys0)) y = (normalize (karatsuba (currentDepth+1) xs1 ys1)) z = (normalize (karatsuba (currentDepth+1) (add xs0 xs1) (add ys0 ys1))) t = (normalize (karatsuba (currentDepth+1) xs0 ys0)) u = (normalize (karatsuba (currentDepth+1) xs1 ys1)) v = z `sub` t `sub` u strategy res = (rnf x) `par` (rnf y) `par` ((rnf z) `par` (rnf t) `par` (rnf u)) `pseq` (rnf v) `pseq` (rnf res)

3 2

Re: Runtime performance degradation for multi-threaded C FFI callback
by John Lato 23 Jan '12

23 Jan '12

Hi Simon, I'm not certain that your explanation matches what I observed. All of my tests were done on a 4-core machine, executing with "+RTS -N", which should be the same as "+RTS -N4" I believe. With 1 Haskell thread (the main thread) and 4 process threads (via pthreads), I saw a significant performance degradation compared to 5 Haskell threads (main + 4 via forkIO) and 4 process threads. As I understand your explanation, if C callbacks are scheduled according to available capabilities, there should be no difference between these situations. I observed this with GHC-7.2.1, however Daniel Fischer reported that, with ghc-7.2.2, he observed different behavior (which matches your explanation AFAICT). Is it possible that the scheduling of callbacks into Haskell changed between those versions? Thanks, John L. > From: Simon Marlow <marlowsd(a)gmail.com> > Subject: Re: Runtime performance degradation for multi-threaded C FFI > callback > To: Sanket Agrawal <sanket.agrawal(a)gmail.com> > Cc: glasgow-haskell-users <glasgow-haskell-users(a)haskell.org> > Message-ID: <4F1D2F4D.9050709(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 21/01/2012 15:35, Sanket Agrawal wrote: >> Hi Edward, >> >> I was just going to get back to you about it. I did find out that the >> issue was indeed one GHC thread dealing with 5 C threads for callback >> (1:5 mapping) - so, the C threads were blocking on callback waiting for >> the only GHC thread to be available. I updated the code to do 1:1 >> mapping - 5 GHC threads for 5 C threads. That proved to be almost >> linearly scalable. > > This is almost right, except that your callbacks are not waiting for a > GHC *thread*, but what we call a "capability", which is roughly speaking > "permission to execute Haskell code". The +RTS -N option chooses the > number of capabilities. > > I expect that with -N1, your program is spending a lot of time just > switching between the different OS threads. > > It's possible that we could make the runtime more flexible here. I > recently made it possible to modify the number of capabilities at > runtime, so it's conceivable that the runtime could automatically add > capabilities if it is being called from multiple OS threads. > >> John Latos suggested the above approach two days back, but I didn't get >> to test the idea until now. >> >> It doesn't seem to matter whether number of GHC threads are increased, >> if the mapping between GHC threads and C threads is not 1:1. I got 1:1 >> mapping by doing forkIO for each C thread. Is it really possible to do >> 7:5 mapping (that is 7 GHC threads to choose from, for 5 C threads >> during callback)? I can't think of a way to do it. Not that I need it. I >> am just curious if that is possible. > > Just think of +RTS -N7 as being 7 *locks*, not 7 threads. Then it makes > perfect sense to have 7 locks available for 5 threads. > > Cheers, > Simon

3 4

Straight-line single assignment in C--
by Edward Z. Yang 23 Jan '12

23 Jan '12

Hello all, I was wondering if the following style of register assignment ever shows up in C-- code generated by GHC: a = R1 I32[a] = 1 a = R2 I32[a] = 2 That is to say, there are two disjoint live ranges of a: we could rename all instances of a in the first and second lines to something different without affecting the semantics (although maybe affecting register allocation and stack spilling.) asdf = R1 I32[asdf] = 1 a = R2 I32[a] = 2 But C-- is not in SSA form, and even when no loops are involved it seems that some naughty code generator could reuse a variable. This is pretty inconvenient, because I want to record this information a = R1 // used only once I32[a] = 1 a = R2 // used only once I32[a] = 2 in a map: a -> used only once But since the register names go all the same place this may end in tears. If multiple assignment is rare enough in straight line code, I might be able to take the conservative approach and just say a -> used multiple times Which I don't think will cause any problems in the inlining step later. But I don't have a good sense for this. Edward

2 2

Runtime performance degradation for multi-threaded C FFI callback
by Sanket Agrawal 23 Jan '12

23 Jan '12

I posted this issue on StackOverflow today. A brief recap: In the case when C FFI calls back a Haskell function, I have observed sharp increase in total time when multi-threading is enabled in C code (even when total number of function calls to Haskell remain same). In my test, I called a Haskell function 5M times using two scenarios (GHC 7.0.4, RHEL5, 12-core box): - Single-threaded C function: call back Haskell function 5M times - Total time 1.32s - 5 threads in C function: each thread calls back the Haskell function 1M times - so, total is still 5M - Total time 7.79s - Verified that pthread didn't contribute much to the overhead by having the same code call a C function instead, and compared with single-threaded version. So, almost all of the increase in overhead seems to come from GHC runtime. What I want to ask is if this is a known issue for GHC runtime? If not, I will file a bug report for GHC team with code to reproduce it. I don't want to file a duplicate bug report if this is already known issue. I searched through GHC trac using some keywords but didn't see any bugs related to it. StackOverflow post link (has code and details on how to reproduce the issue): http://stackoverflow.com/questions/8902568/runtime-performance-degradation-…

3 4

named pipes
by Serge D. Mechveliani 21 Jan '12

21 Jan '12

Dear GHC team, I am testing the IO operations of GHC with the Unix named pipes (in ghc-7.01 under Debian Linux). In the below example, the pipe pair are created by > mkfifo toA > mkfifo fromA, `main' in Main.hs opens toA for writing, opens fromA for reading, outputs "A1" to toA. The C program fifo2 opens toA for reading, opens fromA for writing, inputs a string from toA, prints "done" to the screen (fromA is not really used, but will be needed in future). The effect is that fifo2 (on terminal-2) hangs silent, while Main.hs (on terminal-1) does its part. If I remove the fopen(..fromA..) call in fifo2.c, then it runs as expected (after this example is fixed, fifo2 will need to write to fromA). Main.hs is built by ghc --make Main, The C program is built by gcc -o fifo2 fifo2.c First, ./fifo2 is run on terminal-2, then ./Main is run on terminal-1. The source is quite small: -- Main.hs --------------------------------------------------------- import System.IO (IOMode(..), IO(..), Handle, openFile, hPutStr, hFlush) dir = showString "/home/mechvel/ghc/notes/npipe/" toA_IO = openFile (dir "toA") WriteMode :: IO Handle fromA_IO = openFile (dir "fromA") ReadMode axiomIO :: Handle -> String -> IO() axiomIO h str = do hPutStr h str hFlush h putStr "hFlush done\n" main = do h <- toA_IO putStr "str1 --> " axiomIO h "A1\n" ----------------------- fifo2.c ------------------------------------- #include <stdio.h> #include <string.h> #define BOUND 64 static char str[BOUND]; main() { int l, i; FILE *toA, *fromA; toA = fopen("/home/mechvel/ghc/notes/npipe/toA", "r"); if (toA == NULL) {perror("fopen(toA, r) failed: "); return;}; fromA = fopen("/home/mechvel/ghc/notes/npipe/fromA", "w"); // ! if (fgets(str, BOUND, toA) == NULL) { perror("fgets(str, bound, toA) failed: "); return; }; printf("input = %s\n", str); printf("done\n"); return; } --------------------------------------------------------------------- Can you, please, explain the effect? Regards, ------ Sergei mechvel(a)botik.ru

2 3

strange behavior of let in ghci
by Kazu Yamamoto 20 Jan '12

20 Jan '12

Hello, I met strange behavior of let in ghci 7.0.4. The following works well. > :m Data.List > let compFst (n1,s1) (n2,s2) = compare n1 n2 > maximumBy compFst [(1, "boo"), (3, "foo"), (2, "woo")] (3,"foo") But if I bind "maximumBy compFst" to "chooseMax" with "let", it causes error: > let chooseMax = maximumBy compFst > chooseMax [(1,"boo"),(3,"foo"),(2,"woo")] <interactive>:1:33: No instance for (Num ()) arising from the literal `2' Possible fix: add an instance declaration for (Num ()) In the expression: 2 In the expression: (2, "woo") In the first argument of `chooseMax', namely `[(1, "boo"), (3, "foo"), (2, "woo")]' It's very strange to me. Why does this happen? ":t" says: > :t maximumBy compFst maximumBy compFst :: Ord a => [(a, t)] -> (a, t) > :t chooseMax chooseMax :: [((), t)] -> ((), t) I'm writing a tutorial of Haskell and I would like to define chooseMax in ghci with "let" without specifying its signature. --Kazu

3 3

PolyKinds: couldn't match kind `BOX' against `*'
by Reiner Pope 18 Jan '12

18 Jan '12

Hi all, I think I've found a GHC bug in PolyKinds, but I'm not sure if it's a bug, or whether I misunderstand GHC's kind system. Consider this module: > {-# LANGUAGE PolyKinds #-} > > module Test where > > data Proxy t = ProxyC > > test :: Proxy '[Int, Bool] > test = ProxyC -- doesn't compile > -- test = undefined -- compiles Under ghc-7.4.0.20111219, this fails to compile, with error message > /tmp/test3/Test.hs:8:8: > Couldn't match kind `BOX' against `*' > Kind incompatibility when matching types: > k0 :: BOX > [*] :: * > In the expression: ProxyC > In an equation for `test': test = ProxyC I think GHC is wrong in flagging an error here. Here's how I understand it. The type constructor Proxy has kind > Proxy :: forall (k :: BOX). k -> * The value constructor ProxyC has type > ProxyC :: forall (k :: BOX). forall (t :: k). Proxy t The type '[Int, Bool] has kind > '[Int, Bool] :: [*] But what is the sort of [*]? The GHC manual (http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/kind-polymorph…) says "all kinds have sort BOX", and so we should have > [*] :: BOX (1) However, the error message above seems to suggest that > [*] :: * (2) which disagrees with (1). To add to the confusion, note that the module compiles if the line "test = ProxyC" is replaced by "test = undefined". So it seems that (1) holds when checking the type signature, but (2) holds when checking the expression. As I said, I suspect this is simply a GHC bug, but I'm not sure. Should I post a bug report on GHC Trac? Cheers, Reiner

2 1