Bert Freudenberg wrote:
On 10.11.2009, at 09:00, Andreas Raab wrote:
... make the Squeak VM be "truly event driven" that is invoke it in response to OS or other events instead of having the VM poll.
Don't have time to really get involved but I like the idea :)
I am interested as well. On a related issue, another programmer is working on the "announcements for i/o events" idea we briefly discussed in the beginning of the year.
About having the scheduler in the image rather than in the VM, that is how Self does it. A friend of mine started his PhD thesis using Squeak but switched to Self because of this feature even though I showed him that you could use a few tricks to change the behavior of the Squeak scheduler in interesting ways (I have implemented real-time scheduling with stuff like first-deadline-first, rate monotonic and so on using a higher priority thread waiting on the timer as the actual scheduler).
About to pros and cons of having platform dependent code in the image, there is an interesting discussion in the "Dorado" chapter of the green book. My proposal to the SqueakNOS group was that we could have two images: a small headless one with all the SqueakNOS drivers and primitives and a normal one with the user application. The second image would send messages to the first one for all its i/o so no code would directly access the hardware. In practice, you have the same protection as if there low level stuff were in the VM (or some underlying OS) and the image stays clean of any platform dependency. But if you really know what you are doing, you can call up remote debuggers, inspectors and browser on the first image and it will feel like all this stuff is implemented in the image instead of the VM.
-- Jecel