Some senseless babbling from Jonathan De Boyne Pollard to Peter Knapper
on 11-15-99  13:23 about Clunker update...

 PK> A later fixpak for Warp 3 added a facilty to better manage what is 
 PK> called "Single Input Queue" lockups. 

 JDBP> *Synchronous* Input Queue.

 JDBP> Repeat after me:

 JDBP> "Presentation Manager is multithreaded, always has been, and
 JDBP> has always had multiple input queues, one per application
 JDBP> thread.  Presentation Manager is multithreaded, always has
 JDBP> been, and has always had multiple input queues, one per
 JDBP> application thread. Presentation Manager is multithreaded,
 JDBP> always has been, and has always had multiple input queues, one
 JDBP> per application thread ..." 
 JDBP> It's the fact that raw input is taken synchronously from the mouse and
 JDBP> keyboard into the various *multiple* application message queues that is
 JDBP> the problem.  If it were taken asynchronously, there wouldn't be a
 JDBP> problem. 

That seems an odd, if not somewhat incorrect, way of putting it.

The root of the problem is the different between WinSendMsg() and
WinPostMsg().  The former blocks while awaiting a response.  The latter
returns only an indicator of whether or not the message was successfully
stuffed into the message queue in question (which, incidentally, has a
default size of 10 messages).

The reason PM is synchronous is because it uses WinSendMsg() for *all*
messages that it sends to applications, regardless of whether or not a
meaningful response is required.  The consequence is that the registered
window procedure must return before PM is free to send messages to other
queues.

This was a design decision to make it easier for Windows programmers to
migrate to OS/2, without nuking themselves with the new multiple-thread
possibilities.  With an asynchronous model, having multiple threads with
multiple queues requires a certain amount of logic to make sure that
messages are processed in the correct order (since there's no necessary
connection between the chronology of messages, and the chronology of thread
scheduling).

Win9x/NT have an asynchronous model, and most Win32 are poorly written,
from an interface standpoint, because of it.

The "fix" in OS/2 that was added with a Warp 3 fixpack just waits the
specified amount of time before deciding that a thread which hasn't
answered the message yet won't answer it at all, after which the
application is taken out of the loop until it responds to future messages.
I'm not sure exactly how it's done, but there's probably a proxy put in to
respond to messages on behalf of the application (returning a safe but
meaningless return), which in turn waits for the application to provide an
actual response, after which it should take itself out of the proxy
position.

I've been looking at the possibility of kludging the PM to make it
asynchronous (since most applications wouldn't break if it were), but it's
not a simple matter.

Mike Ruskai
thannymeister@yahoo.com


... I never miss Rush Limbaugh! He's far too big a target!

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
114/477
143/1