Hi Lex,

> Whoa....  The Unix VM relies on being polled for almost every event it
> can generate. 

Hm ... really interesting. I was actually considering to switch to the
aioPoll mechanism (mostly for not having to deal with "wild threads" in a
few not-so-time-critical areas where it is known that things will take a
while and sub-millisecond responses don't matter as much) but this sheds a
new light on the issue...

> How about we use a 1 ms interval instead of 500 ms?  Platforms that
> don't use the function won't notice the difference, because 
> they'll have the functions stubbed out.  However, platforms that do
> use the function, will have a remarkable improvement in the latency
> between events and when Squeak notices them.  In short, if you need
> this function, you really need it!  Is there much reasoning being 500
> ms or was that just what got stuck in there at the time?

Well, actually the Unix VM abuses ioProcessEvents here as this is supposed
to handle user input. The only reason why it gets called every 500ms at all
is to allow interrupt keys to get through even if in busy loop (in a
non-threaded VM you would loop forever otherwise). 

I guess what we _should_ be doing here is something in #checkForInterrupts
which covers the "poll often for io activity" case (as fetching user input
is something that is typically expensive and I probably wouldn't want to mix
up the "quick" with the "slow" check). So, for example, we could change it
to something like:

Interpreter>>checkForInterrupts
	"... yaddaya ..."
	now = lastTick ifFalse:[self ioPollEvents].

which will check as often as your msec resolution supports (note that this
requires the interruptChecksEveryNms to be set appropriately too). I'd be
happy with the above.

Oh, by the way, one trick I'm using lately to get msecs resolution for
timers is to provide a hardware interrupt (similar to itimer) which resets
the interruptCheckCounter therefore forcing an interrupt check every msec.
This has not shown any negative side effects sofar (running 1000 checks per
second is really cheap these days ;-) and would give you a guarantueed msecs
response check for the above.

> > The problem with accessing Sensor directly is that it interferes
> > with some deep notions of Morphic. If you write your own UI framework
> > you are free to do whatever you want but if you want to play within
> > the existing framework then you better agree on the rules.
> 
> In general, yes, but just *looking* at the mouse state should 
> not throw Morphic into a tizzy, should it?  Is this quantum Squeak?  :)

In a way, it really is! Much of this is in the (mostly outdated) interwoven
expectations by various clients. There are some contradicting assumptions in
the interplay between Sensor's original behavior and what is provided by
EventSensor. For example, in order for EventSensor to provide any "current"
state (e.g., Sensor's state is polling and EventSensor simulates the
behavior) it needs to process any pending events from the VMs event queue.
And it just so happens that it also needs to dump the event afterwards as
otherwise it might report this event to Morphic. Consider what this means
for something like "Rectangle fromUser" - here, you'd get the
mouseDown/mouseUp events _after_ Rectangle fromUser completes.

Because of the above (polling Sensor and assuming that anything seen by it
cannot be reported afterwards) there are some quantum effects here ;-)

> I had the impression that John was seeing actual laggy *behavior*, not
> just a lot of signals to the semaphore.  If there was no observable
> behavior (short of someone prodding with tracing tools :)) then never
> mind me.

I don't exactly know what John's observation was (or more exactly: I don't
know how to duplicate it) so I can't really comment on it.

> Similarly, accessing Display in general will cause problems if Morphic
> is running, but also the problems you see are predictable based on the
> most intuitive mental model, ie that Morphic refreshes its stuff onto
> Display whenever it feels like it.  Reading from Display won't cause
> Morphic to even notice.

Well, no. First of all, you don't expect Display to _change_ while you read
it - but you do expect Sensor to change (BIG difference - if we can agree
that a busy-loop will always answer the same if executed on Sensor we'd have
none of the trouble).

And secondly, you may _not_ get any predicable results if you bypass all of
Morphic's mechanisms - as an example, the Balloon engine may (and for the
most part will) batch its operations and only after it executes #flush the
effects are known to be visible. 

Cheers,
  - Andreas