Original from  IVAN TODOROSKI  to ALL on 11-13-1998
Original Subject: the PM message queue

                         ---------------------------------------

IT>   Why is it that when you double click on the Drive A: icon the clock
IT>   cursor appears and there is nothing you can do untill the folder
IT>   opens?
IT>   You can see that the OS is running perfectly, just start a window with
IT>   DIR /S in it before trying to open the Drive A: folder. You'll notice
IT>   that the background activity doesn't stop (unlike Win95), but you
IT>   still can't click on any icon or switch to any window untill the
IT>   folder opens. Similar thing happens when starting some other programs
IT>   or WPS objects.
IT>   Only the user input is blocked, while the rest of the programs run
IT>   totaly unhindered. I think it is very sad that for all that they did,
IT>   the designers of OS/2 didn's pay attention to this little detail.
IT> 
IT>   A mis-behaving application can (and does) sometimes even block the PM
IT>   in this way, if it dies or hangs in middle of its message processing.
IT> 
IT>    The only way is to kill the WPS with some ctrl-alt-del monitoring
IT>    utility, or press ctrl-esc and wait until the "application not
IT>    responding" dialog pops up (which doesn't always work).
IT> 
IT>    I have heard that this is because the PM has a single serialized
IT>    message queue for all applications, and no application can receive
IT>    messages while another is processing its message. A solution to
IT>    this would be multiple asynchronous message queues for each
IT>    application.

 Yes, this is the dreaded synchronous input queue "problem". (single 
input queue is a misnomer). 

 Some background. PM takes each event from the mouse, keyboard, pen,
etc queues and passes it to the input queue of the app. There are
multiple system input queues (as above) and at least one message 
queue per windowing application in the system. 
 WinSendMsg is used to deliver the messages (events) to the 
application queue. WinSendMsg will cause a wait for the application to 
return before continuing. 
 There is also a WinPostMsg API call that does not "wait" but just 
places the event on the application's input queue and continues. PM 
does not use this API to deliver events to applications. 

 Take a look at the PM programmer's reference and pay particular 
attention to the above 2 API's. That is the core of the whole 
difference between a synchronous and an asynchronous design. 

IT>   Well, to tell you the truth, I'm not really sure what all this means,
IT>   since I don't know that much about message processing, so if someone
IT>   could enlighten me on the internal mechanisms of the PM message
IT>   processing, message queues, and explain why a single message queue
IT>   prevents concurrent processing of messages etc. I'd be most grateful!
IT> 
IT>    Please don't "soften" the explanation too much, just
give the hard
IT>    technical information (to the best of your knowledge of course), and
IT>    if I still don't understand, I'll ask again, don't worry. :)
IT> 
IT>    Win98 doesn't seem to have this problem, since you can always click
IT>    on the Start button (when it isn't crashing that is), and if
IT>    Microsoft managed to implement this in their crappy OS, I don't see
IT>    why the brilliant IBM programmers from the OS/2 team couldn't?
IT>    Especially since it doesn't seem that hard compared to all the work
IT>    they've already put in this master-piece of OS design?

 Win3.1 used WinSendMsg to deliver events to applications, as does 
OS/2's PM. If you look closely at the design of a synchronous input 
delivery mechanism, you will quickly see that multiple threads in the 
application are a requirement. A thread to handle the user input and 
one (or more) threads to do the "work". The problem in Win 3.1 is that
applications could not have multiple threads, so all the "work" had to
be done on the only unit of execution the application had. This lead 
to certain programming habits for Windows programmers. Habits that 
were carried to OS/2 (all the work done at event reception) and Win32. 
 MS decided they couldn't retrain all those programmers, so in Win32 
(NT and Win9x) they used a WinPostMsg style API to deliver messages to 
the apps.. 
  
 There are the same amount of "queues" in Win3.1, PM, and Win32. The 
only difference is in the way the events are delivered to the apps.. 
WinSendMsg in a synchronous model and WinPostMsg in an asynchronous 
model.
 A synchronous model is much more predictable from an application 
programmer's point of view, especially if a multi queue application 
(or multiple applications communicating with each other) needs to 
*know* what sequence the events are delivered in (which could change
the behaviour). Programmers have to do some pretty nasty things to
decide the "correct" behaviour in an asynchronous model. The simplest
is to only have one input queue per "application" and
"redispatch"
events to appropriate threads of the application synchronously (sound
familiar?).
 In a multi threaded OS, the "prefered" design is usually synchronous. 

 If you have multithreaded applications dependent on the synchronous 
delivery of events, they will "break" badly if the model is suddenly 
changed to asynchronous. PM's current model has been around since 1.1 
days, and there are apps that properly use and depend on this model. 
 On the other hand, Win32's "heritage" is from the Win3.1 days where 
the programs only had a single thread, and a single application input 
queue (you can only have one thread). 

 There are advantages and disadvantages to each model. The "system" 
will stay more responsive to the user in an asynchronous model no 
matter how poorly the application progranmmer builds his app, but good
programmers will *still* use multiple threads so the *app* stays 
responsive even in the async model. And when you get to more complex 
apps with interacting message processing threads the sync model is 
much simpler for the programmer to implement on. 

IT>    Apparently XFree86/OS2 also has multiple message queues, since you
IT>    can always click around the desktop and switch windows no matter
IT>    which application is loading and what it is doing. So, it can be
IT>    done on OS/2!

 Sure it can. See the differences above between WinSendMsg and 
WinPostMsg. If you want to build a "front end" to all the events (IE: 
your app needs to understand which underlying "app" the event needs to 
be delivered to) you can deliver via WinPostMsg. 

IT>   Is there a patch, a FixPak or a workaround that would fix this, or is
IT>   there a third party solution which can make the PM use multiple
IT>   asynchronous queues?

 It would take a fairly major change to PM (and other parts of the 
system, WPS is a prime example) to implement. You would also break 
any apps that depend on the sync model (all the examples I know of are
from corporate custom apps). 

IT>    Is there ANY way for programmers outside of IBM to do this, is it a
IT>    matter of rewriting and replacing a PM DLL(s), where is the problem?

 The only way for programmers outside of IBM is via the XFree86 
method. Essentially replacing the input model with their own, and it 
would *only* work for apps that understood (or didn't care) about an
async model. 


   Denis       

 All opinions are my very own, IBM has no claim upon them
. 
. 
.
 

 



--- Maximus/2 3.01