lurking signals in EventSensor

Lex Spoon lex at cc.gatech.edu
Sat Jul 5 16:17:05 UTC 2003


"Andreas Raab" <andreas.raab at gmx.de> wrote:
> > Why 500 ms?  You can check from ioProcessEvents() and get them much
> > more frequently. 
> 
> But ioProcessEvents get only called every 500ms unless you query explicitly.
> Which is exactly what stimulating the input semaphore does.

Whoa....  The Unix VM relies on being polled for almost every event it
can generate.  That includes sound buffering and socket events.  This
would explain at least some of the wierd socket performance people on
Squeak/Unix have reported:  if you note that the idle loop will wake up
*immediately* in response to an event, you get to the situation where a
busy Squeak will take 0.5 seconds to respond to a socket event, while an
idle Squeak responds immediately.  This should also cause problems for
sound playing when Squeak is busy.

Yep!  I just tried playing the Fun with Music song with two slightly
different busy loops:

	[ true ] whileTrue: [ ]     "hiccups at a 0.5 second interval"

	[ true ] whileTrue: [Sensor mousePoint]   "plays beautifully"


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?


> 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?  :)

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.

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.


Lex



More information about the Squeak-dev mailing list