I was thinking about something similar today.

My fantasy is to have a smalltalk system that's friendly to professional
software developers and it occures to me that the ability to run a program
in is own memory space making it free of the possibility of being reverse
engineered, might be important to some developers.  But you'd still want to
be able to communicate with the smalltalk desktop, etc, thus the message
passing.

And speaking of concurency, another thing that I think would make squeak
more attractive to developers would be to make the user interface run in a
separate, preemtive thread or threads.

The current design where any program can bring the user interface to a dead
halt effectively crashing the desktop is unacceptably anacronistic.  For
instance, if you start Squeakmap on a system with a slow modem internet
connection, the whole desktop is locked out for minutes.  If an error
occures in the wrong part of the negotiation, Squeak is permanently locked
up and the only thing you can do is kill the process.

Joshua Scholar

----- Original Message ----- 
From: "Colin Putney" <cputney at wiresong.ca>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Saturday, January 21, 2006 10:56 AM
Subject: Re: yet another smallest snapshot, and a visualization


>
> On Jan 21, 2006, at 12:28 AM, tim Rowledge wrote:
>
> >> This is interesting to me. Do you think it is feasable to take out
> >> all of the process management from the VM and put it back in, say,
> >> via a plugin?
> > I think so. No need for the special objects array or Processor
> > instance if the saved context oop is either explicitly saved in the
> > image header or simply put somewhere by convention (like nil true
> > and false used to be) which would be trivial with Craig's version
> > of the tracer. You could start a copy of a VM for each process and
> > terminate it when the process concludes. This VM would need no
> > process handling stuff such as wakeHighestPriority but might need
> > some semaphore stuff?
> > Debugging might be fun. Coordinating threads would have the
> > potential for getting to be as awful as java. On the other hand it
> > wold be an interesting way of making completely separated cells of
> > objects each running their own process and having to communicate
> > only via proper interfaces instead of messing in a global object
> > soup. All sorts of fun possibilities if one has the tim and funding
>
> Indeed. The end result would be message-passing concurrency, rather
> than shared-state concurrency. Each VM instance would be a Vat/Island/
> Task and you'd have distant object references for sending messages
> between them. VM instances could also be on a separate thread, in a
> separate process or on a separate machine, depending on what kind of
> performance characteristics you were looking for, pretty much
> transparently. Beautiful.
>
>