On 10/24/07, Igor Stasenko siguctua@gmail.com wrote:
Sorry for spurious replies.. but.. this statement means that your processes are not so cheap as Erlang ones.
Why not? At this point in time (afaik) they do the exact same thing in all but one case (communication between 2 "green" processes in the same image).
By passing a single object to new process you could trigger a cloning a substantial part of image in this case (read - megabytes of data).
Yes, you can. But this isn't the common case.
Or even if not cloning, then marking objects as read-only, or creating a 'hollow' references to objects, which is too have own costs - extra space and access time.
Well, I have no plans of doing "futures". Others are well down that path, so no need for me to duplicate their research. As far as immutable references, all class have a header with various flags, I would only need one more for mutability. Such a change does scare me a bit because the VM would have to be changed that all instVar sets do an extra check, which would impact non-concurrent code as well, but if it could turn out to be a good trade off vs. doing a deep copy every time.
Even for spawning a process which doing no more than adding 1+1 i need to copy/mark a SmallInteger class and all its references, until i mark everything reachable from it..
Bad example. :) SmallInteger isn't mutable and isn't an object.
But I understand what you mean, the required traversals do sound expensive, but this has to be done *every time* when you send between two images anyway. Lets not optimize prematurely. :)
Honestly, i can't see how this concept can be considered cheap and scalable.
A system with 9 9's of reliability comes to mind. :)
http://www.cincomsmalltalk.com/userblogs/ralph/blogView?entry=3364027251
But really, as soon as you talk between two systems, no other approach is better. A "futures" concept can lazily load the data, saving time when parts of a structure aren't used, but what are the numbers on this? How often do you send a message with a % of unused data high enough to offset the complexity cost of the "futures" mechanism?
Yes, interprocess communication between two same-image process would be a disadvantage, but I'm pretty sure Erlang started this way and optimized from there. That's my plan as well.
After all, we don't know how expensive this would actually be in practice anyway. It's easy to come up with theoretical examples that cripple the system, but will anyone actually do this? And if they do, it will break and they can code around it.
Back before Unix, people were trying to figure out ways to ensure resource deadlocks can not happen. This theoretical problem effectively crippled them from releasing a system. Unix simply ignored it. They gave you tools to see you had a dead lock, and a way to kill dead locked processes. Seamed to work out for them. :)