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
