|
devvvy wrote:
THUS FAR there isn't ONE SINGLE argument that justify against use of Thread.Sleep against SCENARIO 2.
As Pete already told, you are ignoring the comments that we made for Scenario2. See my answer.
|
|
|
|
|
i pointed out timer + event handler as an alternative in the first place, but it's more lines of code for no additional benefit than a simple while+Sleep
dev
|
|
|
|
|
I haven't read the article at all, but I'll give you another reason why it's evil. Every once in a while, you can get this little cryptic error message and you've got absolutely no clue as to what it means or why you're getting it:
"The CLR has been unable to transition from COM context #x###### to COM context #x###### for 60 seconds. The thread that owns the destination context/apartment...blah blah blah"
Why does this happen?? Well, you get this mesage onyl when running under the debugger. Usually it's because Thread.Sleep has been called for greater than 60 seconds or there is a long running operation going on on a thread hosting a message pump. STA COM is accomplished through message passing and if those message don't get processed ... kaboom!
|
|
|
|
|
ok, that's if the worker thread has a message pump - if not nothing wrong.
dev
|
|
|
|
|
No, it's not. Do you know how times I've seen Thread.Sleep show up on the UI thread?? LOTS!
|
|
|
|
|
still - there's nothing against SCENARIO 2, if it's not a UI thread or one with a message pump.
Thread.Sleep isn't evil - it's just uncool. It's uncool because most developers tell each other it's uncool to do so.
dev
|
|
|
|
|
OK, it's "uncool" because most people (noobs) use it like they use PictureBox. They use it without knowing it's limitations and without knowing that there are far better alternatives to it.
|
|
|
|
|
it's a simple reliable picture box. if people use it for SCENARIO 1/3 it's just absurb in the first place.
but SCENARIO 2 it's just not much to talk about - the fact there is simply because people wasting each other time trying to complicate otherwise very simple Thread.Sleep
dev
|
|
|
|
|
Oh but Thread.Sleep is not so simple. Using it has vast implications on the functionality of the rest of your app. That's why so many noobs use it and can't figure out why their app doesn't work properly or, as you mentioned, you can't shutdown a service without timing out the Service Manager.
|
|
|
|
|
I saw two arguments against using Thread.Sleep for scenario 2
a. From you: Thread.Sleep screw up message pump IF you do this on UI Thread (But why'd you Thread.Sleep on UI in the first place!)
b. From Pete: Application exit
Both are valid arguments - But I don't think I stumble across these in other places at all. They deserve more visibility I now agree - Thread.Sleep is evil.
(And can be replaced/avoided by one line timer+handler if you wrap it up in one blocking function call)
Thank you!
dev
modified 19-Feb-13 20:29pm.
|
|
|
|
|
There is one case in which I have used it where it is actually useful to slow things down for the user.
The case in point is an update to an application - sometimes the update is so small that all the user would see is a number of dialogues and progress bars flashing on the screen leaving them to wonder if the update has taken place.
So I introduced a four second sleep in order to allow the user to see that something was happening.
It has saved me from having to say "yes the update did take place, it was just very small" - that comfortable warm feeling is very important to the user.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Or something like this:
public class Utility
{
private static readonly object SyncLock = new object();
public void WaitForTime(int milliseconds)
{
lock (SyncLock)
{
Monitor.Wait(SyncLock, milliseconds);
}
}
public WakeAllThreads()
{
lock (SyncLock)
{
Monitor.PulseAll(SyncLock);
}
}
}
|
|
|
|
|
Thanks Pete! Much appreciated 
I shall now use that method - it would be nice if Microsoft deprecated the sleep method so that people like me were prevented from using it.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
why the appreciation? It's more code than a simple while loop with a Sleep.
why you want be thankful when there really isn't a justification for it?
M$ probably deprecate Thread.Sleep either because its syntax laywer told him so or simply it isn't "cool"
dev
|
|
|
|
|
devvvy wrote: why the appreciation? It's more code than a simple while loop with a Sleep.
So, you think he has to write this out every time? Chuck it in a library and you're done - a simple
new Utility().WaitForTime(5000);
|
|
|
|
|
Peter - this is nice/good idea. But this detracts the discussion to get to the bottom:
SCENARIO 1/3 is just plain stupid to use Thread.Sleep - so just forget it.
SCENARIO 2 - there's yet one single real justification to establish "Thread.Sleep" is *Evil*
(as i pointed out in very beginning timer+event handler *can* be alternative - but why bother)
dev
|
|
|
|
|
devvvy wrote: But this detracts the discussion to get to the bottom
No it doesn't. It shows alternatives. The reason people are using the term "Evil" (and I think this is the word you're getting hung up on) is because threading isn't easy. It isn't trivial. But Thread.Sleep makes it appear as though it is because it's a convenience to hide the complexity, and sooner or later, this complexity creeps out and rips your face clean off. Subtle bugs creep in and they are hugely difficult to track down because they are timing based, and that timing is not predictable, because Thread.Sleep isn't predictable. The OS can actually do different things depending on what you've done with it.
|
|
|
|
|
Thanks Pete - I saw your argument on application exit.
Now I would conclude Thread.Sleep is evil for all SCENARIO 1,2,3
Big Thank you!
dev
|
|
|
|
|
devvvy wrote: why the appreciation? It's more code than a simple while loop with a Sleep.
why you want be thankful when there really isn't a justification for it?
Because someone, especially as it is a person I don't personally know, went out of their way to offer me help.
In my books that deserves my appreciation 
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
right, but do you see the point on why you need replace Thread.Sleep for SCENARIO 2 with ten more lines of code (re-implement with Timer+Event handler)?
If no, your *thank you* will confuse other users for taking that really "Thread.Sleep" is evil, casting further confusion and un-necessary complication on this otherwise simple subject (You should thank those syntax lawyers for this).
That's how we never get to bottom of things
dev
|
|
|
|
|
Why is that better? Actually isn't that worse because when you call WakeAllThreads it will wait on the lock and your app will be unresponsive in all threads (including the one you're sending a wakeup call from)?
|
|
|
|
|
That's just a paste of some code I use to wake things up to kill all the threads (this is the scenario I talk about above). Monitor has a simple Pulse method as well to wake a single thread before the timeout expires.
|
|
|
|
|
there's still no justification to not just do a simple while+Thread.Sleep for SCENARIO 2 if the thread isn't an UI thread (Despite how uncool it has become to Thread.Sleep because syntax lawyers tell us so)
dev
|
|
|
|
|
Let's have the same discussion on;
GOTO
- On Error Resume Next
- GC.Collect
- Application.DoEvents
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Let's not 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
