[Vm-dev] An event driven Squeak VM

[Andreas Raab]

John M McIntosh wrote:
> Ok, well

So does that mean you are:
[ ] in favor,
[ ] against such a change,
[ ] don't care,
[ ] think it can't work at all?
I'm not clear about your reply you seem to be saying all of the above at 
some point or other.

Cheers,
   - Andreas

> 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:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
> 
> 
> 
>