Well ok, that's a pretty good break down of the problems of such a
thing.  Though it wasn't my idea and I'm not invested in it.

Of course the one thing I have to disagree with in your message is the
comment about an object responding to multiple messages.  I wouldn't
want that.  If you want an object to respond to more messages
concurrently make more of them.

On 10/25/07, Peter William Lount <peter at smalltalk.org> wrote:
>
>  Jason Johnson wrote:
>  On 10/24/07, Sebastian Sastre <ssastre at seaswork.com> wrote:
>
>
>  So I'm stating here that in a smalltalk image of the future *every object
> should have a process*. Every instance. All of them.
>
>  That is an interesting idea. That would open a door to a new way of
> Garbage collection, because it can then be tied to the exit of a
> process.
>
>
>
>  Said that I return to the problem you stated about the need of copy copy
> copy, saying that this premise changes things and you don't need to copy
> anymore because a VM like that, no matter who or when, an instVar of an
> object is to be modified it will provide you of guarantee that the write
> will be made by the process that corresponds to that instance.
>
>  Yes, in such a system, you don't need to copy because all that gets
> passed around are references to processes.
>
>
>
>  hi,
>
>  What? That just won't work. Think of the memory overhead.
>
>  Tying an object instance to a particular process makes no sense. If you did
> that you'd likely end up with just as many dead locks and other concurrency
> problems since you'd now have message sends to the object being queued up on
> the processes input queue. Since processes could only process on message at
> a time deadlocks can occur - plus all kinds of nasty problems resulting from
> the order of messages in the queue. (There is a similar nasty problem with
> the GUI event processing in VisualAge Smalltalk that leads to very difficult
> to diagnose and comprehend concurrency problems). It's a rats maze that's
> best to avoid.
>
>  Besides, in some cases an object with multiple threads could respond to
> many messages - literally - at the same time given multiple cores. Why slow
> down the system by putting all the messages into a single queue when you
> don't have to!?
>
>  Tying an object's life time to the lifetime of a process doesn't make sense
> since there could be references to the object all over the place. If the
> process quits the object should still be alive IF there are still references
> to it.
>
>  You'd need to pass around more than references to processes. For if a
> process has more than one object you'd not get the resolution you'd need.
> No, passing object references around is way better.
>
>  Even if you considered an object as having it's own "logical" process you'd
> get into the queuing problems hinted at above.
>
>  Besides objects in Smalltalk are really fine grained. The notion that each
> object would have it's own thread would require so much thread switching
> that no current processor could handle that. It would also be a huge waste
> of resources.
>
>  Again, one solution does not fit all problems - if it did programming would
> be easier.
>
>  All the best,
>
>  Peter
>
>
>
>
>