🚀 go-pugleaf

In article <1992Aug14.003106.24719@hellgate.utah.edu> brian%jaguar.cs.utah.edu@cs.utah.edu (Brian Sturgill) writes:
>In article <1992Aug13.173409.25915@njitgw.njit.edu> dic5340@hertz.njit.edu (David Charlap) writes:
>...
>>They have similar concepts, but the MS API makes you do more work.
>>You have to call functions that, IMO, should be called automatically
>>when the program loads.
>
>Agreed, though NT fixes one important problem that PM still has.
>If one PM app blocks to do something time consuming (instead of
>using a thread) then all PM programs will be hung waiting for that
>PM app to finish. This happens because PM has one global event queue.
>Win32 has an event queue per process (like X does).
>
>Brian

Brian,

How does NT (or X) handle the problems of having multiple event queues? I
remember reading Dror and Lafore's discussions of the need for a single
event queue, and they offered the following situation:

	User clicks on an icon, and _knowing_ the application intimately,
	moves the mouse over to where a button WILL appear, clicks there.
	[ie., just like type ahead]. If you have multiple event queues,
	then you have no clue which process handles the second click.
	So the result is unpredictable.

	In the case of a single event queue, the process controls exactly
	what does happen. ie, it acts like a 'disable interrupts' 
	directive, till it is setup. If indeed the user is to be able to
	go and click somewhere and have another app take action, then
	the first process does this by immediately returning control to
	the system and proceeding via a second thread. Else, it keeps control.

So ... how IS the user protected in the case of multiple event queues? How
can he be assured that the time ordering of his mouse or keyboard actions
is preserved? For eg, 

	Suppose one icon backs up a log file, and another icon deletes
	the log file <stupid eg, but possible>. And the user rapidly
	but sequentially clicks first on the backup and then on the
	delete. How can he be assured that the backup happened BEFORE
	the delete? Or are we simply relying on the fact that computers
	are faster than people?

hari
hsr@uclaph.physics.ucla.edu