Why do you think it's a lot? MVar are a teeny tiny and convenient primitive of communication, and I don't see why they wouldn't suit your need. Sure a throwTo would do the trick... But they're is "do the trick" and "do the job", you see?
Using STM and TVars *would* be kind of overkill. 2012/2/8 JP Moresmau <jpmores...@gmail.com> > Hello, I'm wondering what's the best strategy to use in the following > scenario: > - 2 threads > - One perform some work that will take time, possibly go on forever > - Another waits for user input (like commands from the keyboard) > that affects thread 1 (causing it to stop, in the simplest case) > > I've read a bit on MVar and channels, but they seem to be a lot for > cases where the reading thread block for input. In my case, I expect > to have "something" that thread 2 updates when an event occur, and > thread 1 checks it regularly. So thread 1 should not block, but should > check "is there something" and there is, act on it, otherwise continue > doing what it was currently doing. I suppose I could just tryTakeMVar > on a MVar, but is there something more adapted to my needs? > > Thanks! > > -- > JP Moresmau > http://jpmoresmau.blogspot.com/ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe