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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
