Re: time delay
- From: "Alexander Grigoriev" <alegr@xxxxxxxxxxxxx>
- Date: Thu, 2 Jun 2005 21:31:38 -0700
Another serious problem here is that in general, you cannot reliably compare
tick count with the expected value. Counters can overflow.
One should compare difference between starting tick count and current tick
count, with a desired value.
In Linux sources, there is a bad habit of comparing 'jiffies' against the
target time. Unfortunately, this may break at around 470th day of uptime.
"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:1giu91tg6qjb26uhg12uara5fstulrdfl1@xxxxxxxxxx
> Pick any value for your delay. I can guarantee that it will be wrong. This
> is exactly the
> WRONG way to wait for an application to enter its message loop. Look at
>
> WaitForInputIdle
>
> which is the correct way to wait for a child process to come up. Note that
> like all wait
> operations, this blocks the waiting thread, so if the thread is a main GUI
> thread, you
> should not do a wait there; instead, you should spawn another thread which
> does the
> WaitForInputIdle and posts a message back to the main GUI thread when the
> created process
> is ready to accept input.
>
> Generally, if you are in a situation where polling is required, you should
> always rethink
> the problem to see if polling can be avoided.
>
> For some details on how to use a separate thread to handle blocking
> requests and provide
> asynchronous notification, see my essay on asynchronous process
> notification on my MVP
> Tips site.
> joe
>
.
- Follow-Ups:
- Re: time delay
- From: Joseph M . Newcomer
- Re: time delay
- References:
- time delay
- From: GT
- Re: time delay
- From: Tim Ward
- Re: time delay
- From: GT
- Re: time delay
- From: Joseph M . Newcomer
- time delay
- Prev by Date: Re: ascii files + unicode application
- Next by Date: Re: Multi Threading Options
- Previous by thread: Re: time delay
- Next by thread: Re: time delay
- Index(es):
Relevant Pages
|