<div class="gmail_quote">On Thu, Nov 12, 2009 at 6:56 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
On 10.11.2009, at 09:00, Andreas Raab wrote:<br>
<br>
> ... 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.<br>
<br>
Don't have time to really get involved but I like the idea :)<br>
<font color="#888888"><br>
- Bert -<br>
</font></blockquote></div><br><div>Same here (I've only skimmed this thread)...I think making the VM event driven is a great idea (generally speaking). One benefit is that it lends itself well to wrapping an image/vm as a shared library with efficient inbound calls. It's also very similar to what you'd need for running on bare hardware where input is eventful (via interrupts). I would just say that the code listening for and processing the events should be done in Smalltalk as much as is practical at this time.</div>
<div><br></div><div>In the case of running on bare hardware, an interrupt might actually be interrupting interpret(), so you would want to handle that interrupt quickly and safely (from a concurrent access perspective)...for example, you might want to queue an event in some safely shared structure and exit. To allow for this and similar circumstances involving shared libraries...I could imagine two interfaces...queueEvent() and interpret().</div>
<div><br></div><div>Just some thoughts.</div><div><br></div><div>- Stephen</div>