Re: [Haskell-cafe] Concurrency strategy for 2 threads and rare events
Thank you all, I've used a simple IORef and that did the trick. JP 2012/2/8 Edward Amsden eca7...@cs.rit.edu: If you only need one structure for communication (e.g. neither thread needs to lock multiple things) you might consider using an IORef, and writing/polling it with atomicModifyIORef. It's cheaper than an MVar for the case where you don't need to lock multiple threads. On Wed, Feb 8, 2012 at 2:45 PM, JP Moresmau jpmores...@gmail.com wrote: No, I meant they seem to be mainly for the use case where the reading thread blocks for more input, and maybe there's a simpler/more efficient way to quickly check if an event has occurred, that's all. If there isn't then a MVar it will be. JP On Wed, Feb 8, 2012 at 7:35 PM, Yves Parès yves.pa...@gmail.com wrote: 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 -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Edward Amsden Student Computer Science Rochester Institute of Technology www.edwardamsden.com -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Concurrency strategy for 2 threads and rare events
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
Re: [Haskell-cafe] Concurrency strategy for 2 threads and rare events
You could use throwTo to raise an exception in the thread you want to stop. Otherwise, having some variable (IORef, TVar, MVar) that the long running thread occasionally checks seems like a good solution. Erik On Wed, Feb 8, 2012 at 17:04, JP Moresmau jpmores...@gmail.com wrote: 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
Re: [Haskell-cafe] Concurrency strategy for 2 threads and rare events
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
Re: [Haskell-cafe] Concurrency strategy for 2 threads and rare events
No, I meant they seem to be mainly for the use case where the reading thread blocks for more input, and maybe there's a simpler/more efficient way to quickly check if an event has occurred, that's all. If there isn't then a MVar it will be. JP On Wed, Feb 8, 2012 at 7:35 PM, Yves Parès yves.pa...@gmail.com wrote: 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 -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency strategy for 2 threads and rare events
If you only need one structure for communication (e.g. neither thread needs to lock multiple things) you might consider using an IORef, and writing/polling it with atomicModifyIORef. It's cheaper than an MVar for the case where you don't need to lock multiple threads. On Wed, Feb 8, 2012 at 2:45 PM, JP Moresmau jpmores...@gmail.com wrote: No, I meant they seem to be mainly for the use case where the reading thread blocks for more input, and maybe there's a simpler/more efficient way to quickly check if an event has occurred, that's all. If there isn't then a MVar it will be. JP On Wed, Feb 8, 2012 at 7:35 PM, Yves Parès yves.pa...@gmail.com wrote: 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 -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Edward Amsden Student Computer Science Rochester Institute of Technology www.edwardamsden.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
