> > From: Jiansen He <[email protected]> > > Hi cafe, > > I wounder if it is possible to tell a haskell system that two computations > with side effects could be executed concurrently. > > Here is an affected example: > > Suppose two people want to compare their age, but do not want to leak their > personal information. The following program reads one person's age after > another then send back compared result. > > age :: IO () > age = do > i <- readIntFrom a > j <- readIntFrom b > writeTo a (i-j) > writeTo b (j-i) > > How can I express the fact that two readings could be carried out in any > order?
The best approach is probably to fork a thread for each concurrent evaluation. There are a few packages on Hackage that can help with this; I've used threads[1] and spawn[2] successfully. If the "readIntFrom" function is meant to be responding to a client, a threaded model may make sense organizationally, but for this to be a performance benefit there needs to be sufficient work for each thread to carry out. Haskell threads are lighter than Posix threads, but there's still overhead involved. There is an alternative I hesitate to mention because it involves some voodoo, but Roman Leshchinskiy came up with a clever technique that might be appropriate if you want the behavior of "par" but for IO[3]. [1] http://hackage.haskell.org/package/threads [2] http://hackage.haskell.org/package/spawn [3] http://unlines.wordpress.com/2010/04/21/sparking-imperatives/
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
