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
