[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:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
More information about the Vm-dev
mailing list