Hi stepharo, I was looking for tom van cutsem's PhD, since you mentioned it, but did not find it. Do you have a link? I am attaching my business plan to you, to answer your question asking what is my goal. That's high-level. Low-level, what I am doing: I require an object-capability system, so I am reconstituting SqueakElib and will be looking at VM and networking areas to fully support capabilities and piconet formation. Robert On 10/24/2015 03:43 AM, stepharo wrote:
Hi robert
thanks for refreshing me (I read E some year ago) and I read the PhD of tom van cutsem. Now what are you doing? What is your goal?
Stef
Le 22/10/15 15:11, Robert Withers a écrit :
On 10/22/2015 06:19 AM, stepharo wrote:
Which kind of migration example you have in mind that would not be supported? An example would help.
Well, my pics will demonstrate. I am interested in doing more than mappping ivars or a class rename. I want to do a total substitution, then a further substitution on the receiving, import side:
Vat1: anObject (Class A) ---> On wire: desc (Descriptor) ---> Vat2: aProxy (Class FarERef)
A desc is substituted for a PassByProxy object, then a FarERef is substituted for the desc.
#fuelAccept: is a serialization side method.
If Fuel supports substitution on serialization, I don't understand why no substitution support on materialization.
There was a reason, which I cannot remember completely. Maybe Martin or Max can remember.
It seems your focus was pickling to disk then back. My focus is distributed proxy graphs, which has different use cases.
I'm interesting in knowing more :) Especially Vat and others.
Firstly, I should credit these ideas: I leaned of Elib 9 years ago, from http://erights.org.
A vat is an event-loop. This ensures single-threading with only one thread executing a stack as it schedules to activity. A vat is conceptually a stack and a queue. This is an executing stack of immediate calls and a queue of eventual sends that will be scheduled into the stack as evaluates. When you have a farReference to an object in a different vat, then you need to serialize the graph of arguments sent to the remote object with an eventual send: to queue the send in the remote vat, pending evaluation as a stack.
When a graph is serialized, any PassByProxy objects sent as an argument to a remote method evaluation must be substituted on serialization with a descriptor describing the export of that far reference. This descriptor substitution is not a Fuel migration between versions of one object class nor is it a Fuel substitution, which replaces a subset of ivars, it is a true substitution, a descriptor of class FarDescriptor replaced for an arbitrary PasssByProxy object...let's say Customer <name, age, lastFourSSN>. So aCustomer <name: "Robert", age: 45, lastFourSSN: 9876> will get substituted with aFarReferenceDesc <wireId: 1, wireCount: 1>. On the receiving side, who sees this FerReference, if gets substituted again for a FarRef.
aCustomer ---> farDesc ---> farRef
Does this help to answer your questions? Fire away with more questions and I will try to answer. Reading about Elib on the erights site is another great source of information, sicne these guys came up with it.
My thoughts in the VM are to add a pool to the stack and the queue of an event-loop. For processes/continuations what are waiting for a signal, they are not scheduled into the queue. I believe that this model is a good one for a single-image-threaded execution machinery: a scheduling event-loop. This is pure intuition.
Best, Robert
Stef