[Pharo-project] [Vm-dev] Re: The roadmap aka fight plan to make image control host window

Igor Stasenko siguctua at gmail.com
Wed Sep 26 08:14:48 EDT 2012


On 26 September 2012 13:12, Fernando Olivero <fernando.olivero at usi.ch> wrote:
> Igor, i agree 100% percent with you!
>
> VM shouldn't have all the responsibility of handling a "single UI window".
>
> I've tried in the past to look at VM code, which handles this
> responsibility and change it, (no UI handling in the VM) ..but it
> proved to be a difficult task! We need a simpler,
> cleaner VM,   pluggable  UI handling would be awesome!.
>
> Do we need the pointer or Null at all in the VM? Cant the io handling
> be done completely separate from the VM? A native app for each
> platform, or something built using NB.
>

This is highly platform-specific.
The ioProcessEvents called by VM during interrupt , so,
platform-specific code can
use it to signal any pending external events.
Interrupts is also used by scheduler to switch to another process when
something happens (like socket has new data to read, semaphore
signaled etc).
So, if VM won't support interrupts it will be highly problematic to
support green threading execution model.
And, of course, an interrupt is naturally a well-defined safe point in
VM execution.
So it is logical to have an entry point there, where plugin(s) can
hook-in and add own custom event handling procedure,
without need for patching a single global ioProcessEvents() function
over and over again.

If at some point you'll have two independent modules (plugins) in VM
which want to put own custom handling code there,
you can always do it like following pseudocode:

(during plugin initialization)
oldHandler := ioProcessEvents.
ioProcessEvents := &myHandler.

(during call )
myHandler
   self doMyHandling.
   call oldHandler


Now, of course it is a question, how often you may need that: a module
which adds own custom handler for VM interrupt.
Maybe we don't need that much flexibility? But do others see other way
of freeing VM from assumptions and tight coupling with
different parts of system?

-- 
Best regards,
Igor Stasenko.




More information about the Pharo-dev mailing list