[Haskell-cafe] Re: ANN: Future 1.1.0 concurrency library

[Neal Alexander]

ChrisK wrote:
> Hello,
> 
>   As a side effect of the discussion of the new C++ future/promise 
> features at http://lambda-the-ultimate.org/node/3221 I have implemented 
> a Haskell package called "future" at
> 
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/future
> 
> This ought to do what C++ standard futures/promises do, plus a bit 
> more.  The main operation is
> 
>  > forkPromise :: IO a -> IO (Promise a)
> 
> This sets the "IO a" operation running in a fresh thread.  The eventual 
> result can be accessed in many ways (non-blocking, blocking, blocking 
> with timeout).
> 
>  > let one :: Int; one = 1
>  > p <- forkPromise (return (one+one))
>  > x <- get
>  > y <- wait
> 
> x is an Int with value 2.
> y is an (Either SomeException Int) with value (Right 2).
> 
> The useful thing about futures, as opposed to various IVar packages, is 
> handling  the case where the forked operation ends with an exception.  
> The exception becomes the return value of the promise.  The "get" 
> operation rethrows it, the "wait" operation returns it as (Left ...).
> 
> There is also an "abort" command to kill a promise.  The dead promise 
> may then have an exceptions as its value.
> 
> The "plus a bit more" than C++ is the nonblocking "addTodo" feature.  
> This takes a continuation function from the "Either SomeException a" to 
> an IO operation. These continuation functions get queued and they are 
> run immediately after the the forked operation completes.  Once 
> completed any new "addTodo" continuations run immediately.
> 
> These continuations allow you to race a list of action and take the 
> first one done, or to collect the answers as they complete into a Chan.  
> Both of those options are demonstrated in Future.hs as racePromises and 
> forkPromises.
> 
> It should be safe to use "unsafePerformIO . get" or "unsafePeformIO . 
> wait" to get lazy access to the result, which is itself immutable once set.
> 
> Cheers,
>   Chris

I used something similar to this for a monadic opengl "RPC" mechanism.

The need was for transparently creating OGL objects from any context.

Returning thunks that block on the result when finally evaluated works 
out real nice in practice. Its easy to manage, and performs better than 
dealing with several OS threads and GL contexts.