> From: "Raab, Andreas" <Andreas.Raab at disney.com>

> > I think, there're two important functions:  One to tell the
> > VM about a semaphore on which - I guess - the Smalltalk code
> > will wait for the next event.  And another to retrieve that
> > event from the VM.  The mac VM seems to allocate a circular
> > buffer with 1024 elements to store elements.  However, I
> > wonder why the code to signal the semaphore is
> > commented out.  Doesn't that means, the whole event stuff
> > doesn't work yet?
>
> It works perfectly. The issue with the semaphore is a bit more  
complicated.
> Since almost all VMs currently use a single thread for running both, 
> interpret() and the event processing loop, we have to be OUT OF  
INTERPRET()
> in order to receive an event. This means that as long as none of  
the ioXYZ
> functions is called (which may call some OS level function, which  
may in
> turn return an event or call some callback) you will not receive  
any event
> at all. Understood so far?!

Someone will probably shoot me if I say "architectural mismatch" one  
more time , but this is a perfect description of one... ;-)

> The above basically implies that - given Squeak is running a tight  
byte code
> loop in a single process - no events will ever be reported to it.

As an experiment, I actually  augmented a VM with the feature to  
drop it out of the interpret() loop, with apparently no ill effects.   
I also saw that the Mac browser plugin does this, as it has to   
because otherwise the architectural mismatch with the browser  
architecture would simply make it impossible to run inside the  
browser.

Wouldn't it be better if the top-level morphic loop just simply  
dropped out of interpret() when it is done?  Then you could just  
simply and truly wait for an event and restart the interpreter when  
one arrives (with the proviso that you need synthesized events for  
timer/background tasks).

> They're still polled. The key issue in the VM event stuff was not  
loose user
> input events anymore.

The problem I've seen is that events sometimes *do* get lost, but in  
the image, not between the image and the VM.  The 'place' they get  
lost seems to be the same place that is responsible for at least some  
of the sluggishness.

Marcel