Hi Andreas & Ian,
doesn't separating the interface functions (I/O, display, other) result in (shudder!) an appartment like environment: every such interface function can/will be process-local and passing args (shudder!!) has to be done by means of marshalling.
Besides of that: good idea, I like it. Would allow running several versions of the same thing in parallel.
/Klaus
On Thu, 13 Apr 2006 22:53:31 +0200, Ian Piumarta piumarta@speakeasy.net wrote:
Hi Andreas,
What would happen if we changed the VM so that we fetch the specialObjects array from the active process? In other words, each process could potentially carry its own VM environment which effectively describes its own variant of the VM state. With the effect being that different processes could potentially have different versions of class SmallInteger etc.
The basic question here is: Can you guys see any reason why this *wouldn't* work? Is there anything I'm overlooking? Any situations in which this would cause problems while (say) interrupt processing or somesuch?
The spirit of this I like a lot.
A few things off the top of my head... The VM caches some objects for speed (nil, true, false) that you'd have to reload at process switch. You still wouldn't have complete isolation of the VM internals between processes. They'd all have to agree on the processor scheduler (or keep activeProcess apart from it); the formats of the splObj classes couldn't change too much (changes in splObjs do not affect the assumptions in the way primitive access fixed fields -- or you could make the primitive table process-local too ;-); compact classes would have to be the same (or non-overlapping) for any pair of processes that share instances; semaphores would have to be reloaded at process switch unless you admit the possibility of some processes hijacking interrupts, low space, etc. from the installed handlers.
Of course, the correct solution is to get rid of the VM entirely. (By assuming the splObjs subsume the interesting aspects of VM internals and then making them process-local, you are essentially trying to pull most of the VM implementation up into userland with per-process granularity on customisation of its behaviour.)
Cheers, Ian