Luke Palmer | 8 Oct 02:29

ANNOUNCE: Data.IVar 0.1

Several very elegant FRP approaches are emerging, most visibly FRP.Reactive, which rely on blocking on multiple variables at once, continuing when the *first* of them is available. . . inside an unsafePerformIO, so the beautiful STM "orElse" solution is not available.  The current solution is to race threads against each other, and have the one that finishes first kill the other one.  This is implemented, for example, in Data.Unamb.  However, our empirical tests have shown that the GHC scheduler is not *quite* good enough to handle this efficiently, and ends up introducing too much latency and nondeterminacy.

The Data.IVar module, just uploaded to hackage, provides an alternative to thread racing as a solution to this problem.  It provides *write-once* variables which can be blocked on in parallel, without forking any threads or using STM (so it is safe to use in unsafePerformIO).    Example usage from the documentation:

import qualified Data.IVar as IVar
import Control.Concurrent

main = do
   iv <- IVar.new
   iv' <- IVar.new
   forkIO $ threadDelay 10000000 >> writeIVar iv' "my spoon is too big"
   let merger = IVar.read iv `mplus` IVar.read iv'
   print =<< IVar.nonblocking merger   -- most likely "Nothing"
   print =<< IVar.blocking merger      -- waits a while, then prints
   writeIVar iv' "i am a banana"       -- throws error "IVar written twice"

Enjoy!

Luke
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Don Stewart | 8 Oct 08:20
Gravatar

Re: ANNOUNCE: Data.IVar 0.1

lrpalmer:
>    Several very elegant FRP approaches are emerging, most visibly
>    FRP.Reactive, which rely on blocking on multiple variables at once,
>    continuing when the *first* of them is available. . . inside an
>    unsafePerformIO, so the beautiful STM "orElse" solution is not available.
>     The current solution is to race threads against each other, and have the
>    one that finishes first kill the other one.  This is implemented, for
>    example, in Data.Unamb.  However, our empirical tests have shown that the
>    GHC scheduler is not *quite* good enough to handle this efficiently, and
>    ends up introducing too much latency and nondeterminacy.

Cool! Does you IVar implementation have anything in common with previous
proposals for things called IVar (or say, 'ports',
http://www.cse.unsw.edu.au/~chak/haskell/ports/)?

What's the background for this abstraction?

-- Don
Luke Palmer | 8 Oct 08:36

Re: ANNOUNCE: Data.IVar 0.1

On Wed, Oct 8, 2008 at 12:20 AM, Don Stewart <dons <at> galois.com> wrote:
lrpalmer:
>    Several very elegant FRP approaches are emerging, most visibly
>    FRP.Reactive, which rely on blocking on multiple variables at once,
>    continuing when the *first* of them is available. . . inside an
>    unsafePerformIO, so the beautiful STM "orElse" solution is not available.
>     The current solution is to race threads against each other, and have the
>    one that finishes first kill the other one.  This is implemented, for
>    example, in Data.Unamb.  However, our empirical tests have shown that the
>    GHC scheduler is not *quite* good enough to handle this efficiently, and
>    ends up introducing too much latency and nondeterminacy.

Cool! Does you IVar implementation have anything in common with previous
proposals for things called IVar (or say, 'ports',
http://www.cse.unsw.edu.au/~chak/haskell/ports/)?

Yes, I picked up the name from haskell-cafe discussions a while back.  Various forms have been popping in and out of the reactive libraries.

I hadn't seen ports before.

What's the background for this abstraction?

So like I said, I'm not too sure, I just stole the name and vague idea from discussions about it.  As is easily noticed from the jive above, it's motivated by the continuous barrage of suboptimal FRP libraries.  While I'm working on reactive from the top down, this is the beginning of one I have planned, taking baby steps from the bottom up  (and it'll likely get incorporated into reactive too).

Luke
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Jake Mcarthur | 8 Oct 14:28
Favicon

Re: ANNOUNCE: Data.IVar 0.1

On Oct 8, 2008, at 1:36 AM, Luke Palmer wrote:

> What's the background for this abstraction?
>
> So like I said, I'm not too sure, I just stole the name and vague  
> idea from discussions about it.

I believe IVar or something similar used to be in the standard GHC  
libraries a long time ago. Conal had asked at some point why it was  
removed and if it could be added back, but ultimately gave up on that  
path and found another. Upon discovering this as I was working on my  
own from the bottom up, I found a couple ways to implement it and made  
it publicly known, but I never released a library besides some source  
code pastes here and there. So I didn't come up with the idea myself  
by any stretch, but I think I helped repopularize it. I'm attaching  
one of the more well-known variants in case anybody is interested,  
although to be honest I can't remember which one was actually the best  
as I have moved on from this approach.

- Jake

Attachment (IVar.hs): application/octet-stream, 1331 bytes

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Jake Mcarthur | 8 Oct 14:33
Favicon

Re: ANNOUNCE: Data.IVar 0.1


On Oct 8, 2008, at 7:28 AM, Jake Mcarthur wrote:

>  I'm attaching one of the more well-known variants in case anybody  
> is interested, although to be honest I can't remember which one was  
> actually the best as I have moved on from this approach.

I just looked back over it. I had forgotten how far from the original  
idea I had gone. Perhaps this would be better with a different name now.

Jake
Sean Leather | 8 Oct 09:01

Re: ANNOUNCE: Data.IVar 0.1


   forkIO $ threadDelay 10000000 >> writeIVar iv' "my spoon is too big"

   writeIVar iv' "i am a banana"       -- throws error "IVar written twice"

Nice Don Hertzfeldt reference. ;)

If this means nothing to you, here's the animated film from whence this came:
  http://www.youtube.com/watch?v=MuOvqeABHvQ

Sean
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Gmane