- Haskell-Cafe - Haskell.org

RE: [Haskell-cafe] Spurious program crashes
by Simon Marlow 17 Nov '05

17 Nov '05

On 16 November 2005 17:38, Joel Reymont wrote: > I'm getting crashes like this and I cannot figure out what the > problem is. I'm launching a bunch of threads that connect to a server > via TCP and exchange packets. > > I am running operations like connect and receive in a timeout > function that launches two threads and uses an MVar to figure out > who's done first. The timeout function then kills the two threads. > > Any ideas what could be causing this? I feel like a Haskell guinea > pig these days :-). I don't see any reason why you should be getting crashes here, but this is a delicate area (async exceptions + FFI). It's possible there's a bug, but as usual we need to reproduce the symptoms here. Can you help with a repro case? Regarding the behaviour of killThread, I believe the version in GHC is slightly different from the version described in the Asynchronous Exceptions paper, in particular the GHC version blocks until the exception has been delivered to the target thread (use another forkIO to get the fully async version). Cheers, Simon

2 2

ReaderT and concurrency
by Kurt Hutchinson 17 Nov '05

17 Nov '05

I'm writing a program that will be using multiple threads to handle network activity on multiple ports in a responsive way. The treads will all need access to some shared data, so I'm using an MVar. So far so good. The problem is that passing the MVar around everywhere is kind of a pain, so I was hoping to use a ReaderT monad on top of the IO monad to handle that for me. I have that working, but one piece seemed a bit out of place so I wondered if there was a better way. Below is a small test program that presents my question. My program uses forkIO to create the separate threads (Set A), and some of *those* threads will need to create threads (Set B). In order for the ReaderT to handle the environment of the threads in Set B, do I have to perform another runReaderT when forking? Or is there a way to get the ReaderT environment automatically carried over to the newly created Set B thread? See the "NOTE" comment in the code below for the particular spot I'm asking about. > import Control.Monad.Reader > import Control.Concurrent > > type MyReader a = ReaderT (MVar Integer) IO a > > main = do > mv <- newMVar 1 > forkIO $ runReaderT (printAndFork "one" 5) mv > forkIO $ runReaderT (printAndFork "two" 5) mv > getChar -- Pause so the threads can print before program exit > > printAndFork :: String -> Integer -> MyReader () > printAndFork _ 0 = return () > printAndFork str n = do > mv <- ask > lift $ do > modifyMVar_ mv $ \i -> do > print $ str ++ show i > return (i + 1) > -- NOTE: Is this runReaderT necessary to carry the > -- environment to the new thread? Is there a better way? > forkIO $ runReaderT (justPrint $ "inner " ++ str) mv > printAndFork str (n - 1) > > justPrint :: String -> MyReader () > justPrint str = do > mv <- ask > lift $ do > modifyMVar_ mv $ \i -> do > print $ str ++ show i > return (i + 1) > return () Kurt Hutchinson

6 7

RE: [Haskell-cafe] layout problem
by Simon Marlow 17 Nov '05

17 Nov '05

On 16 November 2005 17:15, Christian Maeder wrote: > Simon Peyton-Jones wrote: >> Indeed! I always use braces and semicolons with do-notation. You >> are free to do so too! Nothing requires you to use layout. Indeed, >> you can freely mix the two. > > I would not recommend braces and semicolons, because these allow a bad > layout (easy to parse for a compiler, but hard to read for a human), > unless you invest the time to make a tidy layout despite the braces > and semicolons. (So why not only make a tidy layout?) > > Surely, a different layout may change your semantics (in rare cases). > A missplaced "_ -> error ..." case usually causes a pattern warning. > >>>>> liftIOTrap io = >>>>> do mx <- liftIO (do x <- io >>>>> return (return x) >>>>> `catchError` >>>>> (\e -> return (throwError >>>>> (fromIOError >>>>> e)))) > > I'ld rather avoid the infix `catchError' and write: > > liftIO $ catchError > (do ... > ) $ \e -> I generally prefer to use the "handle" variants rather than "catch": liftIO $ handle my_handler $ do x <- io return (return x) where my_handler e = return (throwError (fromIOError e)) Don't be afraid to name things if it makes your code easier to read. Cheers, Simon

1 0

RE: [Haskell-cafe] Reducing # of context switches
by Simon Marlow 17 Nov '05

17 Nov '05

On 17 November 2005 00:17, Joel Reymont wrote: > The latest GHC docs mention that the -C option takes a seconds value > whereas prior docs mention microseconds. Which is it? > > Also, do I pass +RTS -Cxxx or is it just -C? It is in seconds, eg. +RTS -C0.5 for switches every half a second. I've just fixed and cleaned up the docs a bit. Cheers, Simon

1 0

updated_fwd: unknown/strange object 0
by Joel Reymont 17 Nov '05

17 Nov '05

internal error: update_fwd: unknown/strange object 0 Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, or http://www.sourceforge.net/projects/ghc/ This happened when I tried running with +RTS -C0 -c I think. -- http://wagerlabs.com/

1 0

Hackage or Where to Host Haskell projects, and simple darcsforge description was Re: Making Haskell more open
by Shae Matijs Erisson 17 Nov '05

17 Nov '05

Wolfgang Jeltsch <wolfgang(a)jeltsch.net> writes: > Would it be intended that every Haskell-related project is hosted under > haskell.org? This might be not so nice. And it might be not so nice if most > Haskell-related projects are hosted under haskell.org so that potential users > might only look under haskell.org for projects and miss those that are hosted > elsewhere. Hackage[1] is designed to be the freshmeat and apt-get of the Haskell world. I have a simple plan for a darcsforge as well: If Cabal includes a darcs-repository field, developers will be able to upload their project.cabal file to Hackage or to a darcsforge server. That server will run darcs pull on the repositories once a night or so. The developers can include an index.html in their repo that points to a doc/ subdirectory, or is the entire docs and description for simple projects. That way a single site can host the equivalent of cvs and webspace for darcs. That site could do http://host/projectname urls for each project. This is roughly a darcs equivalent to RSS aggregators. It does require that developers have a publically accessible repo, but anyone can get space from geocities or angelfire for that. Advantages of this include: * easy indexing and searching of projects and sources * easy references to other darcs/cabal projects * host needs nearly zero admin effort, notably zero user accounts required. Disadvantages are: * no bug tracker * no mailing lists Though maybe those could have darcs backends also? Still, this simple darcsforge has an excellent effort to results ratio. I hope to have time to add this sort of thing to cabal and hackage soon. [1] http://www.haskell.org/hawiki/Hackage -- Shae Matijs Erisson - http://www.ScannedInAvian.com/ - Sockmonster once said: You could switch out the unicycles for badgers, and the game would be the same.

2 1

Reducing # of context switches
by Joel Reymont 17 Nov '05

17 Nov '05

Folks, The latest GHC docs mention that the -C option takes a seconds value whereas prior docs mention microseconds. Which is it? Also, do I pass +RTS -Cxxx or is it just -C? Thanks, Joel -- http://wagerlabs.com/

1 0

IO exception not being caught
by Joel Reymont 16 Nov '05

16 Nov '05

Folks, I have a problem catching my IO exception with the code below. The intent is to catch either the IO exception from connectTo (connection refused, etc.) or the timeout. type EngineState = ErrorT String (StateT World IO) fromIOError err = ioeGetErrorString err liftIOTrap :: IO a -> EngineState a liftIOTrap io = do mx <- liftIO (do x <- io return (return x) `catchError` (\e -> return (throwError (fromIOError e)))) mx timeout secs fun = do resultVar <- newEmptyMVar threadId <- forkIO $ do result <- fun putMVar resultVar result forkIO $ do threadDelay (secs * 1000000) throwError $ userError "Timeout" maybeResult <- takeMVar resultVar killThread threadId return maybeResult connect_ :: HostName -> Int -> IO Handle connect_ h p = connectTo h $ PortNumber $ fromIntegral p connect :: HostName -> Int -> EngineState () connect host port = do w <- get let secs = timeout_seconds w h <- liftIOTrap $ timeout secs $ connect_ host port trace $ "Connection established, h: " ++ show h ... Thanks, Joel -- http://wagerlabs.com/

2 3

Spurious program crashes
by Joel Reymont 16 Nov '05

16 Nov '05

I'm getting crashes like this and I cannot figure out what the problem is. I'm launching a bunch of threads that connect to a server via TCP and exchange packets. I am running operations like connect and receive in a timeout function that launches two threads and uses an MVar to figure out who's done first. The timeout function then kills the two threads. Any ideas what could be causing this? I feel like a Haskell guinea pig these days :-). My Cabal build options look like this ghc-options: -fglasgow-exts -Wall -O -debug And the stack trace: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x3139322e 0x0027c174 in s8j1_info () (gdb) where #0 0x0027c174 in s8j1_info () #1 0x0021c9f4 in StgRunIsImplementedInAssembler () at StgCRun.c:576 #2 0x0021cdc4 in schedule (mainThread=0x1100360, initialCapability=0x308548) at Schedule.c:932 #3 0x0021dd6c in waitThread_ (m=0x1100360, initialCapability=0x0) at Schedule.c:2156 #4 0x0021dc50 in scheduleWaitThread (tso=0x13c0000, ret=0x0, initialCapability=0x0) at Schedule.c:2050 #5 0x00219548 in rts_evalLazyIO (p=0x29b47c, ret=0x0) at RtsAPI.c:459 #6 0x001e4768 in main (argc=2262116, argv=0x308548) at Main.c:104 Thanks, Joel -- http://wagerlabs.com/

2 3

RE: [Haskell-cafe] Re: [Haskell] Making Haskell more open
by Simon Marlow 16 Nov '05

16 Nov '05

On 14 November 2005 08:32, Gour wrote: > Nobody said that DocBook does not work fine. However let me quote > SPJ's message: > > <quote> > However, I still wonder if there are things we could do that would > make > it easier for people to contribute. Here are two concrete > suggestions: ^^^^^^^ > - Make it possible for people to add comments, explanations, or > questions to > * The GHC user manual [currently generated using DocBook] > * The Haskell 98 Report > The idea would be that anyone could help improve these documents, > ^^^^^^^^^^^^^^^^^^^ > and that, at least in the case of the GHC user manual, we could > use the comments to help clarify the text. > </quote> > > So, the whole discussion, at least from my side, was to offer > suggestions to make it easier for more people to contribute to the > whole haskell community. With regard to the GHC user manual, I don't think the implication above was that we should change the markup technology (at least, I agree with Sven that DocBook XML is on the whole a reasonable solution). The idea was to make it easy for Joe Programmer to add his comments to the manual, whether by a wiki link or some other clever user-editable content mechanism. In a separate stage the comments could be incorporated into the manual proper by the developers, or just left in place for the edification of other users. Cheers, Simon

1 0