[Haskell-cafe] Tackling IO (the correct way)

Isaac Dupree isaacdupree at charter.net
Thu Aug 23 08:17:52 EDT 2007

Dave Tapley wrote:
> Hi again all, I could do with some design pointers for a project I'm
> working on combining Haskell with a robot.
> My situation is:
> I read sensor data from the robot lazily a line at a time, as soon as
> a line is read in my code sends out a response down a pipe.
> Implemented in this fashion:
>> mapM_ (updateFunction myIORef) fromRobot ::IO ()
>> fromRobot :: String
>> updateFunction :: IORef -> String -> IO ()
> Now I wish to update a HOpenGL window synchronously with this.
> To establish this I make a new HOpenGL window & return an IORef (IO
> ()) which holds the actions to draw my graphics. In this fashion:
>> myIORef <- makeWindow
> --- Above code ---
>> mainLoop
> This can be passed to updateFunction as shown above so every time it
> processes a new line from the robot is can update the graphics via the
> IORef.
> Because neither 'mapM_ (updateFunction myIORef) fromRobot' nor
> 'mainLoop' terminate I've been using 'forkIO' to split one off. This
> way the lazy evaluation keeps running and then window keeps updating
> itself.
> This works, sort of.
> I have problems because the my HOpenGL code also has magic to allow
> you to change the point of view using the keyboard. But when I do I
> get this after a while:
>         Previous intel_span.c:210
>         Current: intel_batchbuffer.c:63
> Can anyone suggest how to resolve this "two functions which never
> terminate but both share IORefs" problem?

Using IORefs in two different threads probably needs MVars [1] or TVars 
(atomically :: STM a -> IO a) [2] instead, to do it safely, which are 
both similar to IORefs (choose whichever interface fits your usage 
better, I guess).  (And using forkOS like Stefan says)

no documentation where it should be: 
but some documentation here: 


More information about the Haskell-Cafe mailing list