Idle
The easiest drop in alternative I was able to find to Thread.Sleep was AutoResetEvent. I'm experimenting with some combination of Task.Delay so additional updates may be forthcoming.
WARNING:
I haven't figured out how to run the existing unit tests since ReSharper just tells me it can't find %project%\bin\Debug\xunit.dll. I think this is due to you running an alpha version of XUnit that the ReSharper plugin doesn't understand. Any help on how to get the tests to run would be greatly appreciated.
I'm assuming I haven't broken anything due to the small change I've made.
Thanks for this @cnwilkin. I'll pull this down after work tonight and take a look.
@half-ogre is the motivation here to move away from Sleep because of my emphatic comments about it?
Nah, just curiosity. I'd like to try using F# agents for this once I get the code moved over to F#, but in the mean-time I don't see the harm in experimenting.
Does the reset event offer any advantage over sleep?
I have no idea. Do you? @cnwilkin?
@cnwilkin:
Any help on how to get the tests to run would be greatly appreciated.
I don't use R# to run tests, so I'm not sure. I use testdriven.net. I can add a script to run the tests in the shell if that helps (something I need to do anyway, really.)
So, I remember hitting some issue when I tried Task.WaitAll with this before, but can't recall what it was now. I'll give this some testing.
Does the reset event offer any advantage over sleep? I have no idea. Do you? @cnwilkin?
No I don't have any idea what the advantages/disadvantages would be I just saw the comment on how there should be a better way to idle and thought I'd check into it.
I don't use R# to run tests, so I'm not sure. I use testdriven.net.
Ok I'll take a look at that thanks!
So if I understand correctly, this is in a loop within the console, right? In that case, I don't see any reason to change this code. You generally want to avoid Thread.Sleep if you have some sort of thread pool to release the thread to. But since this is the Main Thread, there's nothing to release the thread to. Suspending it seems right.
Now, the only disadvantage to sleep is that the thread is suspended for some set period of time and there could be a tiny delay between a new task being ready and us kicking it off. In this case, it doesn't seem so bad.
But to solve that, we'd have to have a listener on some IO port that then kicked off a thread pool thread so that rather than polling, we're responding to messages. That's a bigger change. :smile: