[Vm-dev] An event driven Squeak VM

John M McIntosh johnmci at smalltalkconsulting.com
Tue Nov 10 23:51:13 UTC 2009

Ok, well
On 2009-11-10, at 12:03 PM, Andreas Raab wrote:

> John M McIntosh wrote:
>> Well I'm not sure what exactly you are trying to fix or optimize
> Sorry for not being clear. I'm trying to address several concrete  
> problems:
> 1) Dragging a Squeak main window by its label currently blocks the  
> VM. Sounds stops playing, animations stop animating etc.
> 2) Opening OS file dialogs or context menus block the VM. Same  
> issues. You've had this problem in Sophie, we've added a specific  
> solution for Teleplace and I'd like to generalize this into a  
> generic solution.

These are windows issues?

Ok for os-x these problems don't go away. Why? Well the Squeak is run  
as a part of the main UI thread.  The choice here is:

(a) Run the squeak VM from time to time as a subtask of the UI thread,  
in the past this gave poor performance since the overhead is high, and  
the setup for interp in powerpc was high.
However in this model as it services a UI task  like menu interaction  
then squeak doesn't run.

(b) Run the main UI event processing as a subtask of the Squeak  
thread, the current mode. This stops the VM from running as it  
services UI events, again the VM is calling ioProcessEvent and that
is busy servicing the menu interaction. Cost is cheaper since we just  
ask if there are any events pending every 16ms or so.  This is why  
when on os-x when the morphic task is dead then the VM slowly
responds to window/menu interactions since there is a 1/2 second or so  
ioProcessEvent callback in checkForInterrupts()

So why not run the Squeak VM as a separate thread from the UI Thread,  
yes we do that for the iPhone. However any UI interacts from the VM  
has to run on the UI thread, fine you can work with that.
Now add in desire to run Objective-C methods, easy to deadlock between  
UI Thread callbacks and Squeak thread running message send on UI  
Thread.  Besides all that hassle this applies to FFI
calls where when building Sophie we discovered it was just illegal to  
call Quicktime routines from a background thread.   Starts to get  
complicated, lets add in the fact you cann't even create an
object in a background thread for use on the foreground thread because  
UI objects have semaphores which are thread aware and a cross thread  
lock isn't allowed.

> 3) Make it easy to embed a Squeak VM by making it possible to  
> deliver an event and run the resulting code. Allowing for example to  
> run the VM as a browser plugin by calling interpret() in response to  
> the browser-delivered events.

Been there done that, I think the code is still lurking, something  
about asking if we should terminate the interp() loop for the browser  
to run.

John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:   
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com

More information about the Vm-dev mailing list