Why should I use Sleep () with an infinite timeout?

According to MSDN, Sleep () can be provided with an INFINITE value, which means that the suspension should not time out. "

Why do I need to call Sleep () with an INFINITE timeout in my program?

+4
source share
6 answers

There is no reason why one of his sane minds has ever slept (INFINITE). This is not practical.

This is for generality and symmetry WaitForSingleObject (..., timeout) and SleepEx (timeout), where INFINITE makes sense.

We remind you that SleepEx will try to destroy things from the APC queue of your thread.

+1
source

I used Sleep (INFINITE) and that makes sense. I used it to keep the stream alive. I registered for the WMI notification event (ExecNotificationQueryAsync, which endlessly receives an event notification), then you need to keep the application in active mode. don't know if that makes sense to you.

+4
source

Sleeping without a timeout does not require a timer. This reduces overhead when you expect variable-length expectations, but are absolutely certain that the flow will resume.

+3
source

As far as I know, Sleep, since they introduced SleepEx, it's just a thin, convenient wrapper around SleepEx, and when they rewrote it as a wrapper, they decided to just pass the timeout parameter to SleepEx without processing it anyway. Obviously, in this way the behavior of a function with INFINITE as a timeout also extends to "Sleep" (and therefore should be documented), although without the bAlertable parameter SleepEx it is absolutely useless (Sleep (timeout) is SleepEx (timeout, FALSE), so you there will be endless involuntary waiting).

In Windows CE, perhaps they decided to change this behavior because it was actually stupid, so I believe that Sleep (INFINITE) on CE automatically translates into SuspendThread; however, on Windows, they are probably forced to adhere to β€œsimple” behavior for compatibility reasons.

+3
source

In addition to what was said (mostly expecting an interruption), you can end up with an infinite timeout without being crazy. For example, I have an application (worker) that needs to do 3 different things at a time.

I decided to make each of these works run in new threads and have an infinite timeout in the Main () thread (since the program should not exit, except for the exception being thrown, in which case the whole application restarts), for convenience and readability (I can comment on any of the three works without affecting global behavior or easily divide them into different workers, if necessary).

This probably adds very little overhead compared to having 2 new threads + a main thread doing the third job, but this is negligible given today's performance and computer memory.

+2
source

Well, when we need to wait until ^ C, but we do not want yet (1);

0
source

All Articles