thanks for the info igor. maybe we could plug customized UI handlers for different devices, with different "raw" events. It would make coding and managing each of them, a lot simpler than now.
Fernando On Wed, Sep 26, 2012 at 2:14 PM, Igor Stasenko <[email protected]> wrote: > On 26 September 2012 13:12, Fernando Olivero <[email protected]> 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.
