On Thu, Jul 03, 2003 at 04:55:29AM +0200, Andreas Raab wrote:
> Be that as it may but unless you fix the clients not to use Sensor there is
> really nothing you can do. Sensor polls and because of the VMs event support
> we have to make sure we get the appropriate state pulled in from the VMs
> event buffer. If we don't, then the polling loop will sit there forever.
> 
> Besides, signalling the event semaphore from the VM will only work if you
> have a multi-threaded VM implementation which can process incoming UI events
> in parallel to the VM's loop. If you don't, then you'll only get new events
> every 500ms or so (depending on what your VM interrupt check counter says)
> so not stimulating the input semaphore is not an option given all the
> non-multithreaded implementations.

Why 500 ms?  You can check from ioProcessEvents() and get them much
more frequently.  Does that function really only get called every 500 ms?
That would be a problem on single-threaded VM's, e.g. for sound buffering.


By the way, these messages I'm posting are not theoretical.  They are
closely based on an actual implementation from a few years ago that
predates the current one.  It really does work, even if the user is
switching between Morphic and MVC.  I'm pretty sure I only checked for
events in ioProcessEvents() and in the input primitives themselves.

I also did queue-flushing within the VM, so that I wouldn't have to
have a limit on the number of events, but admittedly that's a matter of
choosing your poison.


> if you want to reduce the needless work
> done here then you need to fix the clients to work with our (not so) new
> assumptions (e.g., being event-driven no client should poll for state and
> expect it to change in its polling loops). Once you do this, you can rewrite
> everything in terms of the morphic hand rather than Sensor's polling API
> (which is the right thing to do).

Yeah, they should mostly be fixed anyway, at least unless you are
working in MVC.  :)

But also, polling Sensor should be a fine thing to do.  One of the selling
points of Squeak at Georgia Tech is that students are in control and that
things they think will work, do work.  In fact, it's not uncommon for them
to write GUI code manually, where they watch the Sensor and update things
on Display as appropriate.  The goal is not *only* to have Morphic
be happy, but  -- at least for us -- to have a simple and comprehensible
system.


Lex