hi,

What? That just won't work. Think of the memory overhead. 
 
I don't give credit to unfounded apriorisms. I think it deserves to be
proved that does not work. Anyway let's just assume that may be too much for
state of the art hardware in common computers in year 2007. What about in
2009? what about in 2012? Remember the attitude you had saying this now the
first day of 2012.
 
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!?

You didn't understand the model I'm talking about. There isn't such a thing
as an object with multiple trheads. That does not exists in this model. It
does exists one process per instance no more no less. I think you're
thinking about processes and threads the same way you know them today. Lets
see if this helps you to get the idea: Desambiguation: for this model I'm
talking about process not as an OS process but as a VM light process which
we also use to call them threads. So I'm saying that in this model you have
only one process per instance but that process is not a process that can
have threads belonging to it. That generates a hell of complexity. The
process I'm saying it's tied to an instance it's more close to the process
word you know from dictionary plus what you know what an instance is and
with the process implemented by a VM that can balance it across cores.
 
I'm not falling in the pitfall of start trying to parallelize code
automagically. This far from it. In fact I think this is better than that
illusion. Every message is guaranteed by VM to reach it's destination in
guaranteed order. Otherwise will be chaos. And we want an ordered chaos like
the one we have now in a Squeak reified image.
 
Clarified that I ask why do you think could be deadlocks? and what other
kind of concurrency problems do you think that will this model suffer?
 
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.
 
Yes of course there will be. In this system a process termination is one of
two things: A) that instance is being reclaimed in a garbage collection or
B) that instance has been written to disk in a kind of hibernation that can
be reified again on demand.  Please refer to my previous post with subject
"One Process Per Instance.." where I talk more about exacly this. 
 
Even if you considered an object as having it's own "logical" process you'd
get into the queuing problems hinted at above.
 
Which I dont see and I ask your help to understand if you still find them
after the clarifications made about the model.
 
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.


And what do you think was going out of the mouths of criticizers of the
initiatives like the park place team had in 1970's making a Smalltalk with
the price of the CPU's and RAM at that time? that VM's are a smart efficient
use of resources?
 
So I copy paste myself: "I don't give credit to unfounded apriorisms. It
deserves to be proven that does not work. Anyway let's just assume that may
be too much for state of the art hardware in common computers in year 2007.
What about in 2009? what about in 2012?"
 
Again, one solution does not fit all problems - if it did programming would
be easier.
 
But programming should have to be easier. Smalltalk made it easier in a lot
of aspects. Listen.. I'm not a naif silver bullet purchaser nor a faithful
person. I'm a critic Smalltalker that thinks he gets the point about OOP and
tries to find solutions to surpass the multicore crisis by getting an
empowered system not consoling itself with a weaker one. Peter please try to
forget about how systems are made and think in how you want to make them.
 
    cheers,
 
Sebastian
 
All the best,

Peter



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20071025/91d1f3d1/attachment.htm