🚀 go-pugleaf

"Rodolfo Frino - Macrosoft" <Microhaven@Atlantis.com> wrote in message
news:4004cafd@newsgroups.borland.com...

> This answer could be incorrect if the thread creates any windows.
> In this case it will be a much better design to use either
> MsgWaitForMultipleObjects() or MsgWaitForMultipleObjectsEx()
> instead of Sleep(), otherwise your system could fall into a deadlock.

A deadlock occurs when "A" waits on "B" which waits on "A", thus creating a
circular dependancy that neither thread can be released from.  Sleep() does
not create deadlocks unless you use INFINITE as the timeout, which you
should never need to do anyway.  Even the documentation states that only an
infinite wait will produce a deadlock when windows are concerned.

> Please update your knowledge about Sleep() from the built-in
> Windows SDK help files.

I'm well aware of those functions.  I'm also well aware that under 99% of
cases, worker threads do not usually need to create their own windows, all
GUI work should be kept in the main thread as much as possible.  The main
exceptions are DDE and COM.  I'm also well aware that the help file is
seriously outdated and incomplete, MSDN has more information about the issue
than the help file does.


Gambit