Here is an issue that is bugging me. I will try to do an experiment to
find out what exactly is going on, but I thought I would throw it out
to see if anyone know already and to make people aware of it.

Has anyone used WinCancelShutdown()? One thing it does, and for which
most people use it, is to cancel a shutdown and re-enter the message
dispatch loop. I have always used it for that myself. But, another
thing it can do is to tell PM never to send a WM_QUIT to that thread,
even though it has a message queue (which it probably will if it has to
do PM'ism things.)

I have seen a number of warnings (in out of the way places) that you
should be careful to call WinCancelShutdown() on all threads except
your one main thread. This is because (or what I have read implies)
that only one WM_QUIT is posted, and the thread that gets it is pretty
much picked at random (if there is more than one thread with a queue.)
The implication is that, if you don't do this, then the thread that has
the message loop will never get see the WM_QUIT so WinGetMsg() will
never return FALSE and, therefore, your program will appear to hang
because the thread that is running the message loop will get stuck in
that loop. I think that we have occasionally seen that occur here at
work, where our programs often tend to be very multithreaded PM apps.

If that is true, i.e. only one WM_QUIT is posted, what happens if you
have multiple threads that have message loops? Is the main thread
responsible for posting WM_QUIT messages to these threads? If so, that
would make it very difficult to provide a black box service that
required background PM threads with message loops. The main thread
logic would have to handle tracking these things, or there would have
to be some registration mechanism that could clean up anything when the
main thread exists.

And, if you just pop up a message box or dialog from another thread
(which is something we do in a number of places), you have implicitly
entered a modal message loop there. So, if the application was
terminated from the outside at that time, would that thread hang up in
the message box (or dialog box) modal message loop? If that is true,
then it would be impossible to have multiple threads that either have a
message loop or that pop up dialogs or message boxes. Or at least it
would be difficult because the main program logic would have to be
aware of this kind of thing at all times and clean them up.

It would seem to make a whole lot more sense to just post a WM_QUIT to
every thread that has a message queue and not worry about it. I wonder
why this is not done? Or maybe it is done and what I have read is not
true. But if it is true, then many people out there doing
multi-threaded PM apps could be in potential danger of having their
programs hang up on exit. It would probably be far enough along to not
be in the task list, but still hung because WinGetMsg() would never
return. If that program maintains named shared resources that were not
explicitly cleaned up before the hang, it would often cause the program
not to run again (because the program's code would try to create these
named resources and fail because they already exist.) The casual user
would not have a clue as to way this was happening. But, if they use
RUNNING or some program like that, they would see the program just
hanging around in the list of running apps.

So, anyone know what the heck is gowin on hea?

___
 X KWQ/2 1.2b X If at first you don't succeed, put it out for beta test (KWQ Beta

--- Maximus/2 2.02