[e-lang] Question on redirectors/whenMoreResolved in the 3-way case, in the middle vat

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark S. Miller]

Have you looked at the Vine? Search for "Vine" at
http://erights.org/elib/distrib/captp/index.html
and in the source code of https://code.google.com/p/caja-captp/

I don't quite understand your question, so I'm not sure if this is even
relevant to the answer. Is it?

I found some more info: it looks as if the Ref in Alice's ProxyResolver
is being GCed, before resolution from Bob. This is specific to my
machinery, but knowing how Elib maintains a reference to the Ref, in this
case, may help make mine better. How does Elib handle this?
Thank you,
- Robert
I am stuck, both conceptually, as well as understanding code I wrote a
long while ago. I was hoping to gain a little insight from the list of the
insides of resolution redirection in the 3-way case. The recent change I
have made results from my thinking I finally understand the ordering that
MirandaMethods ensure. I made changes such that a whenMoreResolved
directly follows the message that generates is by adding to the front of
the msg queue.
In the 3-way case, Carol is sending a message to Alice, passing Bob.
Alice receives the message and executes, which sends a message to Bob, then
returns the result to Carol. In Alice's vat, the DelayedRedirector is
resolved to the RemotePromise of the call to Bob, the return of Alice's
computation and I think it sends whenMoreResolved to the proxy of the new
promise resolver of the send to Bob. What little tracing I have I am
posting below, as well as the DelayedRedirector value() and the
ProxyResolver resolve() code, at the bottom. However, this is my question,
what should the redirector do in Alice's Vat to propagate the resolution
from Bob, back to Carol?
Thank you,
- Robert
// 1) getTheAnswer, which returns 42,
// 2) *hashCode, again 42* and
// 3) *whenMoreResolved*, to forward to the redirector back in Alice.
0 [main] INFO cc.ganymede.pauwau.presentation.AbstractPauwauTest - 3
Introducers starting
549 [main] INFO cc.ganymede.pauwau.presentation.AbstractPauwauTest - 3
Introducers on the air
4553 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[497273074681788564315291637588644948944089734358])
4952 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[497273074681788564315291637588644948944089734358])
4958 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[NearRefImpl(hash: 109537538, receiver: TestObject)])
4998 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[FarRefImpl(hash: 68783569)])
5353 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[-686254831702855955980329529540587585277617841038])
5593 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[-686254831702855955980329529540587585277617841038])
5593 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[NearRefImpl(hash: 1530099003, receiver: TestObject)])
6201 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -1 answerId: -2 resolverId: -2
action: redirectForTheAnswer args: [RemotePromiseRefImpl(hash: 1034568234)])
6203 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -2 resolverId: -2
[-568687285196004884954480990488973591228663758441,
RemotePromiseRefImpl(hash: 1034568234),
-676914875674370369045480105305401075435688776666])
6239 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -2 answerId: -3 resolverId: -3
action: hashCode args: [])
6255 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
1530099003, receiver: TestObject),
-676914875674370369045480105305401075435688776666])
6259 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
6403 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[HouseAtreides:10003/-687934017861573292334955567350102524989066643525,
-676914875674370369045480105305401075435688776666,
6410 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
598908224)])
6411 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
null action: hashCode args: [])
6411 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -1 answerId: -2 resolverId: -2
action: getTheAnswer args: [])
6412 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -2 answerId: -3 resolverId: -3
action: hashCode args: [])
6412 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverOnlyMessage(receiverId: -2 action: whenMoreResolved
args: [RedirectorProxy: FarRefImpl(hash: 177595052)])
6766 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[HouseAtreides:10003/-687934017861573292334955567350102524989066643525,
690984748)])
6767 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
null action: getTheAnswer args: [])
6767 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
null action: hashCode args: [])
6767 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
RedirectorProxy: FarRefImpl(hash: 196981675))])
6768 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[NearRefImpl(hash: 1530099003, receiver: TestObject)])
6769 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[NearRefImpl(hash: 790206055, receiver: 42)])
*6770 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[NearRefImpl(hash: 878991039, receiver: 42)])*
*6771 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[NearRefImpl(hash: 790206055, receiver: 42)])*
6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[FarRefImpl(hash: 1332394016)])
6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[42])
*6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[42])*
*6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[42])*
6806 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverOnlyMessage(receiverId: 3 action: value args: [42])
19932 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -1)
19934 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -2)
19934 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -3)
19984 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -1)
19984 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -2)
19985 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -3)
29679 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -1)
29680 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[FarRefImpl(hash: 734824022)])
29680 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[FarRefImpl(hash: 1223086084)])
29680 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[42])
29681 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -1)
29681 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -2)
29682 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -2)
29722 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -1)
29722 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -2)
29726 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -1)
29726 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -2)
*// DelayedRedirector code:*
public void value(Object obj) throws NotResolvedException {
if(resolver == null)
return;
if(resolver.isFresh()) {
resolver.resolve(obj);
resolver = null;
return;
}
if(RefUtil.isLocal(obj)) {
resolver.resolve(obj);
resolver = null;
return;
}
Ref ref = (Ref)RefUtil.wrap(obj, resolver.handler.getVat());
boolean isLocalToResolverScope = false;
try {
isLocalToResolverScope =
RefUtil.isLocalToScope(resolver.handler.scope, ref);
if(isLocalToResolverScope) {
resolver.resolve(obj);
resolver = null;
return;
}
} catch (Exception e) {
reactToLostClient(e);
}
Pair<PromiseRefImpl, Resolver> pair =
RefUtil.promise(ref.getVat());
Redirector redirector = new Redirector((ProxyResolver)
pair.second());
resolver.getProxy().whenResolved(redirector);
resolver.resolve(pair.first());
resolver = null;
}
*// ProxyResolver code:*
public void resolve(final Object result) throws NotResolvedException {
handler.scope.getVat().sendRunnable(new Runnable() {
public void run() {
if(ref == null)
return;
if(ref.get() == null)
return;
if(Exception.class.isAssignableFrom(result.getClass())) {
}
Ref newRef = RefUtil.wrap(result, handler.scope.getVat());
try {
if (newRef == null)
ref.get().getRefImpl().becomeContext(null);
else
ref.get().getRefImpl().becomeContext(newRef.getRefImpl());
if(RefUtil.isResolved(newRef.getRefImpl())) {
handler = null;
ref = null;
}
} catch (NotResolvedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}});
}
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Robert Withers]

I have a question about elib. Do you use promise3Desc and far3Desc for 2-vat interactions such that a vine is always in play in any interaction?

- Robert

Post by Rob Withers
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark S. Miller]

No, the 2-vat interactions never use, or engage in any way with, vines,
promise3Desc or far3Desc.

Post by Robert Withers
I have a question about elib. Do you use promise3Desc and far3Desc for
2-vat interactions such that a vine is always in play in any interaction?
- Robert
Mark, your instincts were right on, it seems. I have an issue with my use
of the Vine and on reflection it makes perfect sense. I am bending the send
from Carol to Alice over to Bob, so as it is a 3-way interaction, I need a
Vine. In analyzing ELib code, you have 9 references to the Vine's
constructor, while I only have 7 (minus an extra unused constructor I
have). It is going to require some digging to unearth what I am missing,
but the direction is clear. The place it blows up is in my
ProxyResolver.resolve() method, as the WeakReference has lost the ref.
However, this is not where the reference is maintained. I suspect it may
be a lack of an IdentityManager.
I republished my code to: https://github.com/tooantuh/pauwau. The tests
pass, though there is an issue with the RefTests and
TestPauwau2VatException, as well as this issue affecting
TestPauwau3VatFollowOnSend. Additionally, the presentation tests need to
be run one at a time as stopping and starting the Introducers can step on
each other.
thank you,
Robert
Have you looked at the Vine? Search for "Vine" at
http://erights.org/elib/distrib/captp/index.html
and in the source code of https://code.google.com/p/caja-captp/
I don't quite understand your question, so I'm not sure if this is even
relevant to the answer. Is it?

I found some more info: it looks as if the Ref in Alice's ProxyResolver
is being GCed, before resolution from Bob. This is specific to my
machinery, but knowing how Elib maintains a reference to the Ref, in this
case, may help make mine better. How does Elib handle this?
Thank you,
- Robert
I am stuck, both conceptually, as well as understanding code I wrote a
long while ago. I was hoping to gain a little insight from the list of the
insides of resolution redirection in the 3-way case. The recent change I
have made results from my thinking I finally understand the ordering that
MirandaMethods ensure. I made changes such that a whenMoreResolved
directly follows the message that generates is by adding to the front of
the msg queue.
In the 3-way case, Carol is sending a message to Alice, passing Bob.
Alice receives the message and executes, which sends a message to Bob, then
returns the result to Carol. In Alice's vat, the DelayedRedirector is
resolved to the RemotePromise of the call to Bob, the return of Alice's
computation and I think it sends whenMoreResolved to the proxy of the new
promise resolver of the send to Bob. What little tracing I have I am
posting below, as well as the DelayedRedirector value() and the
ProxyResolver resolve() code, at the bottom. However, this is my question,
what should the redirector do in Alice's Vat to propagate the resolution
from Bob, back to Carol?
Thank you,
- Robert
// 1) getTheAnswer, which returns 42,
// 2) *hashCode, again 42* and
// 3) *whenMoreResolved*, to forward to the redirector back in Alice.
0 [main] INFO cc.ganymede.pauwau.presentation.AbstractPauwauTest - 3
Introducers starting
549 [main] INFO cc.ganymede.pauwau.presentation.AbstractPauwauTest - 3
Introducers on the air
4553 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[497273074681788564315291637588644948944089734358])
4952 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[497273074681788564315291637588644948944089734358])
4958 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[NearRefImpl(hash: 109537538, receiver: TestObject)])
4998 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[FarRefImpl(hash: 68783569)])
5353 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[-686254831702855955980329529540587585277617841038])
5593 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[-686254831702855955980329529540587585277617841038])
5593 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[NearRefImpl(hash: 1530099003, receiver: TestObject)])
6201 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -1 answerId: -2 resolverId: -2
action: redirectForTheAnswer args: [RemotePromiseRefImpl(hash: 1034568234)])
6203 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -2 resolverId: -2
[-568687285196004884954480990488973591228663758441,
RemotePromiseRefImpl(hash: 1034568234),
-676914875674370369045480105305401075435688776666])
6239 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -2 answerId: -3 resolverId: -3
action: hashCode args: [])
6255 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
1530099003, receiver: TestObject),
-676914875674370369045480105305401075435688776666])
6259 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
6403 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[HouseAtreides:10003/-687934017861573292334955567350102524989066643525,
-676914875674370369045480105305401075435688776666,
6410 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
598908224)])
6411 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
null action: hashCode args: [])
6411 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -1 answerId: -2 resolverId: -2
action: getTheAnswer args: [])
6412 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -2 answerId: -3 resolverId: -3
action: hashCode args: [])
6412 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverOnlyMessage(receiverId: -2 action: whenMoreResolved
args: [RedirectorProxy: FarRefImpl(hash: 177595052)])
6766 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[HouseAtreides:10003/-687934017861573292334955567350102524989066643525,
690984748)])
6767 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
null action: getTheAnswer args: [])
6767 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
null action: hashCode args: [])
6767 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
RedirectorProxy: FarRefImpl(hash: 196981675))])
6768 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[NearRefImpl(hash: 1530099003, receiver: TestObject)])
6769 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[NearRefImpl(hash: 790206055, receiver: 42)])
*6770 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[NearRefImpl(hash: 878991039, receiver: 42)])*
*6771 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[NearRefImpl(hash: 790206055, receiver: 42)])*
6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[FarRefImpl(hash: 1332394016)])
6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[42])
*6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[42])*
*6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[42])*
6806 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverOnlyMessage(receiverId: 3 action: value args: [42])
19932 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -1)
19934 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -2)
19934 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -3)
19984 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- receiving message: GCAnswerMessage(answerId: -1)
19984 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- receiving message: GCAnswerMessage(answerId: -2)
19985 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- receiving message: GCAnswerMessage(answerId: -3)
29679 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -1)
29680 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[FarRefImpl(hash: 734824022)])
29680 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[FarRefImpl(hash: 1223086084)])
29680 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[42])
29681 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -1)
29681 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -2)
29682 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -2)
29722 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- receiving message: GCAnswerMessage(answerId: -1)
29722 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- receiving message: GCAnswerMessage(answerId: -2)
29726 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -1)
29726 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -2)
*// DelayedRedirector code:*
public void value(Object obj) throws NotResolvedException {
if(resolver == null)
return;
if(resolver.isFresh()) {
resolver.resolve(obj);
resolver = null;
return;
}
if(RefUtil.isLocal(obj)) {
resolver.resolve(obj);
resolver = null;
return;
}
Ref ref = (Ref)RefUtil.wrap(obj, resolver.handler.getVat());
boolean isLocalToResolverScope = false;
try {
isLocalToResolverScope =
RefUtil.isLocalToScope(resolver.handler.scope, ref);
if(isLocalToResolverScope) {
resolver.resolve(obj);
resolver = null;
return;
}
} catch (Exception e) {
reactToLostClient(e);
}
Pair<PromiseRefImpl, Resolver> pair =
RefUtil.promise(ref.getVat());
Redirector redirector = new Redirector((ProxyResolver)
pair.second());
resolver.getProxy().whenResolved(redirector);
resolver.resolve(pair.first());
resolver = null;
}
*// ProxyResolver code:*
public void resolve(final Object result) throws NotResolvedException {
handler.scope.getVat().sendRunnable(new Runnable() {
public void run() {
if(ref == null)
return;
if(ref.get() == null)
return;
if(Exception.class.isAssignableFrom(result.getClass())) {
}
Ref newRef = RefUtil.wrap(result, handler.scope.getVat());
try {
if (newRef == null)
ref.get().getRefImpl().becomeContext(null);
else
ref.get().getRefImpl().becomeContext(newRef.getRefImpl());
if(RefUtil.isResolved(newRef.getRefImpl())) {
handler = null;
ref = null;
}
} catch (NotResolvedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}});
}
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

--
Cheers,
--MarkM
_______________________________________________
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark S. Miller]

Wait wait apologies! You did nothing at all to offend! Really!

I was just saying to a current houseguest last night, as close as I can
remember:

"Have you seen the question Rob Withers has asked lately on e-lang about
captp? It relates to race conditions and GC, but I haven't yet been able to
reload enough context to think about it. Could you have a look?" We then
went off on a long discussion on race conditions in captp-like systems x gc
x partition x malice, how difficult it is to do a full case analysis of the
cross product by hand, and how much automated tools could help. Sadly, we
did not get back to the subject of your question.

True story. I am posting this without first checking with the houseguest,
which is why I'm omitting their name.

I should have said something to explain my lack of response. The rudeness
really is mine.

Thanks for all the reticent help over the years, everyone. It's been
fun. Such a pity that that help seems permanently revoked, like an
untrusted capability. I must not have participated well in the social
context, but that is par for the course for folks with Aspergers, I am
learning. I just can't ever seem to say the right thing and more often
than not, I piss people off. The issue is I truly just don't get it.
Best regards,
Robert
Might someone be able to comment on this, please? It would help me a
great deal. I do not think it is the unimplemented far3Desc situation.
Thanks,
Robert
I see. Could you comment on how a Vine (and promise3Desc/far3Desc) get
introduced into the machinery when a followOn msg gets forwarded to a third
vat? In my example, redirectForTheAnswer sends getTheAnswer to Bob and
returns a RemotePromise, which receives a hashCode followOn msg, forwarded
to Bob.
- Robert
No, the 2-vat interactions never use, or engage in any way with, vines,
promise3Desc or far3Desc.

Post by Robert Withers
I have a question about elib. Do you use promise3Desc and far3Desc for
2-vat interactions such that a vine is always in play in any interaction?
- Robert
Mark, your instincts were right on, it seems. I have an issue with my
use of the Vine and on reflection it makes perfect sense. I am bending the
send from Carol to Alice over to Bob, so as it is a 3-way interaction, I
need a Vine. In analyzing ELib code, you have 9 references to the Vine's
constructor, while I only have 7 (minus an extra unused constructor I
have). It is going to require some digging to unearth what I am missing,
but the direction is clear. The place it blows up is in my
ProxyResolver.resolve() method, as the WeakReference has lost the ref.
However, this is not where the reference is maintained. I suspect it may
be a lack of an IdentityManager.
I republished my code to: https://github.com/tooantuh/pauwau. The tests
pass, though there is an issue with the RefTests and
TestPauwau2VatException, as well as this issue affecting
TestPauwau3VatFollowOnSend. Additionally, the presentation tests need to
be run one at a time as stopping and starting the Introducers can step on
each other.
thank you,
Robert
Have you looked at the Vine? Search for "Vine" at
http://erights.org/elib/distrib/captp/index.html
and in the source code of https://code.google.com/p/caja-captp/
I don't quite understand your question, so I'm not sure if this is even
relevant to the answer. Is it?

I found some more info: it looks as if the Ref in Alice's ProxyResolver
is being GCed, before resolution from Bob. This is specific to my
machinery, but knowing how Elib maintains a reference to the Ref, in this
case, may help make mine better. How does Elib handle this?
Thank you,
- Robert
I am stuck, both conceptually, as well as understanding code I wrote a
long while ago. I was hoping to gain a little insight from the list of the
insides of resolution redirection in the 3-way case. The recent change I
have made results from my thinking I finally understand the ordering that
MirandaMethods ensure. I made changes such that a whenMoreResolved
directly follows the message that generates is by adding to the front of
the msg queue.
In the 3-way case, Carol is sending a message to Alice, passing Bob.
Alice receives the message and executes, which sends a message to Bob, then
returns the result to Carol. In Alice's vat, the DelayedRedirector is
resolved to the RemotePromise of the call to Bob, the return of Alice's
computation and I think it sends whenMoreResolved to the proxy of the new
promise resolver of the send to Bob. What little tracing I have I am
posting below, as well as the DelayedRedirector value() and the
ProxyResolver resolve() code, at the bottom. However, this is my question,
what should the redirector do in Alice's Vat to propagate the resolution
from Bob, back to Carol?
Thank you,
- Robert
// 1) getTheAnswer, which returns 42,
// 2) *hashCode, again 42* and
// 3) *whenMoreResolved*, to forward to the redirector back in Alice.
0 [main] INFO cc.ganymede.pauwau.presentation.AbstractPauwauTest - 3
Introducers starting
549 [main] INFO cc.ganymede.pauwau.presentation.AbstractPauwauTest - 3
Introducers on the air
4553 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[497273074681788564315291637588644948944089734358])
4952 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[497273074681788564315291637588644948944089734358])
4958 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[NearRefImpl(hash: 109537538, receiver: TestObject)])
4998 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[FarRefImpl(hash: 68783569)])
5353 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[-686254831702855955980329529540587585277617841038])
5593 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[-686254831702855955980329529540587585277617841038])
5593 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[NearRefImpl(hash: 1530099003, receiver: TestObject)])
6201 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -1 answerId: -2 resolverId: -2
action: redirectForTheAnswer args: [RemotePromiseRefImpl(hash: 1034568234)])
6203 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -2 resolverId: -2
[-568687285196004884954480990488973591228663758441,
RemotePromiseRefImpl(hash: 1034568234),
-676914875674370369045480105305401075435688776666])
6239 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -2 answerId: -3 resolverId: -3
action: hashCode args: [])
6255 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
1530099003, receiver: TestObject),
-676914875674370369045480105305401075435688776666])
6259 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
6403 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[HouseAtreides:10003/-687934017861573292334955567350102524989066643525,
-676914875674370369045480105305401075435688776666,
6410 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
598908224)])
6411 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
null action: hashCode args: [])
6411 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -1 answerId: -2 resolverId: -2
action: getTheAnswer args: [])
6412 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -2 answerId: -3 resolverId: -3
action: hashCode args: [])
6412 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverOnlyMessage(receiverId: -2 action: whenMoreResolved
args: [RedirectorProxy: FarRefImpl(hash: 177595052)])
6766 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[HouseAtreides:10003/-687934017861573292334955567350102524989066643525,
690984748)])
6767 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
null action: getTheAnswer args: [])
6767 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
null action: hashCode args: [])
6767 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
RedirectorProxy: FarRefImpl(hash: 196981675))])
6768 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[NearRefImpl(hash: 1530099003, receiver: TestObject)])
6769 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[NearRefImpl(hash: 790206055, receiver: 42)])
*6770 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[NearRefImpl(hash: 878991039, receiver: 42)])*
*6771 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[NearRefImpl(hash: 790206055, receiver: 42)])*
6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[FarRefImpl(hash: 1332394016)])
6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
[42])
*6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[42])*
*6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[42])*
6806 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverOnlyMessage(receiverId: 3 action: value args: [42])
19932 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: GCAnswerMessage(answerId: -1)
19934 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: GCAnswerMessage(answerId: -2)
19934 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: GCAnswerMessage(answerId: -3)
19984 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- receiving message: GCAnswerMessage(answerId: -1)
19984 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- receiving message: GCAnswerMessage(answerId: -2)
19985 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- receiving message: GCAnswerMessage(answerId: -3)
29679 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: GCAnswerMessage(answerId: -1)
29680 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[FarRefImpl(hash: 734824022)])
29680 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[FarRefImpl(hash: 1223086084)])
29680 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[42])
29681 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: GCAnswerMessage(answerId: -1)
29681 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: GCAnswerMessage(answerId: -2)
29682 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: GCAnswerMessage(answerId: -2)
29722 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- receiving message: GCAnswerMessage(answerId: -1)
29722 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- receiving message: GCAnswerMessage(answerId: -2)
29726 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- receiving message: GCAnswerMessage(answerId: -1)
29726 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- receiving message: GCAnswerMessage(answerId: -2)
*// DelayedRedirector code:*
public void value(Object obj) throws NotResolvedException {
if(resolver == null)
return;
if(resolver.isFresh()) {
resolver.resolve(obj);
resolver = null;
return;
}
if(RefUtil.isLocal(obj)) {
resolver.resolve(obj);
resolver = null;
return;
}
Ref ref = (Ref)RefUtil.wrap(obj, resolver.handler.getVat());
boolean isLocalToResolverScope = false;
try {
isLocalToResolverScope =
RefUtil.isLocalToScope(resolver.handler.scope, ref);
if(isLocalToResolverScope) {
resolver.resolve(obj);
resolver = null;
return;
}
} catch (Exception e) {
reactToLostClient(e);
}
Pair<PromiseRefImpl, Resolver> pair =
RefUtil.promise(ref.getVat());
Redirector redirector = new Redirector((ProxyResolver)
pair.second());
resolver.getProxy().whenResolved(redirector);
resolver.resolve(pair.first());
resolver = null;
}
*// ProxyResolver code:*
public void resolve(final Object result) throws NotResolvedException {
handler.scope.getVat().sendRunnable(new Runnable() {
public void run() {
if(ref == null)
return;
if(ref.get() == null)
return;
if(Exception.class.isAssignableFrom(result.getClass())) {
}
Ref newRef = RefUtil.wrap(result,
handler.scope.getVat());
try {
if (newRef == null)
ref.get().getRefImpl().becomeContext(null);
else
ref.get().getRefImpl().becomeContext(newRef.getRefImpl());
if(RefUtil.isResolved(newRef.getRefImpl())) {
handler = null;
ref = null;
}
} catch (NotResolvedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}});
}
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

--
Cheers,
--MarkM
_______________________________________________
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

--
Cheers,
--MarkM
_______________________________________________
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark S. Miller]

Post by Mark S. Miller
Wait wait apologies! You did nothing at all to offend! Really!
I was just saying to a current houseguest last night, as close as I can
"Have you seen the question Rob Withers has asked lately on e-lang about
captp? It relates to race conditions and GC, but I haven't yet been able to
reload enough context to think about it. Could you have a look?" We then
went off on a long discussion on race conditions in captp-like systems x gc
x partition x malice, how difficult it is to do a full case analysis of the
cross product by hand, and how much automated tools could help. Sadly, we
did not get back to the subject of your question.
True story. I am posting this without first checking with the houseguest,
which is why I'm omitting their name.
I should have said something to explain my lack of response. The rudeness
really is mine.

Expanding on this a bit, when my only response would be "I don't yet have
anything to say because I haven't yet had the time to dive back into that
area.", my normal inclination is to say nothing rather than that. Next time
I'll remember that a private note to that effect can be more appropriate
than silence.

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark Miller]

Hi Rob, I think I missed something. What do the Agreements 1,2,3, and 4
refer to?

Post by Mark S. Miller

Post by Mark S. Miller
Wait wait apologies! You did nothing at all to offend! Really!
I was just saying to a current houseguest last night, as close as I can
"Have you seen the question Rob Withers has asked lately on e-lang
about captp? It relates to race conditions and GC, but I haven't yet been
able to reload enough context to think about it. Could you have a look?" We
then went off on a long discussion on race conditions in captp-like systems
x gc x partition x malice, how difficult it is to do a full case analysis
of the cross product by hand, and how much automated tools could help.
Sadly, we did not get back to the subject of your question.
True story. I am posting this without first checking with the
houseguest, which is why I'm omitting their name.
I should have said something to explain my lack of response. The
rudeness really is mine.

Expanding on this a bit, when my only response would be "I don't yet
have anything to say because I haven't yet had the time to dive back into
that area.", my normal inclination is to say nothing rather than that. Next
time I'll remember that a private note to that effect can be more
appropriate than silence.
Likewise, I will remain patient and not make assumptions, nor take it
personally. That is at least Agreements 2 and 3, if not 1 and 4, in there,
as well.
- Robert
--
Cheers,
--MarkM
_______________________________________________
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark Miller]

Sorry, I made the assumption! you had heard of them. They are from a
http://www.amazon.com/The-Four-Agreements-Practical-Personal/dp/1878424319
.

Hi Rob, I hadn't heard of them. Since we're talking about captp, with
tongue only slightly in cheek, I'll venture a reinterpretation of them as
best practice advice for writing an agent to participate in a distributed
secure system of mutually suspicious agents.

“The First Agreement: Be Impeccable with Your Word

(Integrity) Don't be malicious. Meet your protocol's / api's / type's
contractual obligations. Don't lie.

The Second Agreement: Don’t Take Anything Personally

When another agent seems to violate its contract, remember that it may not
be a targeted attack against you. It may just be buggy. Or your contract
conformance test may be buggy.
(Like Heinlein's razor <http://muchow.dk/ttrttc/?p=565> but without the
derogatory language. There are plenty of bugs in the world, and we've all
caused them.)

The Third Agreement: Don’t Make Assumptions

(Loose coupling) Your agent's correctness should rely as little as possible
on assumptions about the behavior or state of other agents.

The Fourth Agreement: Always Do Your Best”

(Availability) If the first agreement corresponds to
integrity/safety/consistency, this one corresponds to
availability/liveness/progress. In a distributed system, no one can
guarantee that they will continue to provide good service to well behaved
clients, but one should strive to provide good service as often as possible.

https://experiencelife.com/wp-content/uploads/2011/11/28-the-four-agreements.pdf

I suspect many other valid bits of interpersonal and folksy advice can be
translated into software engineering best practices. After all, we're all
dealing with many of the same abstract coordination problems.

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark S. Miller]

Thanks Mark! This is a wonder and laughter is the best medicine. Does
this mean a distributed system could be viewed as social ecosystem? I like
that concept.

Indeed. I have written extensively on this, starting with the "Comparative
Ecology" paper at <http://e-drexler.com/p/04/03/0321miller1988b.html>. See
also section 4.2 of my thesis. (Best read after rereading Chapter 4
"Programs as Plans".)

So where are the concepts of humor and laughter in distributed systems?

On that one, I'm at a loss ;).

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark Miller]

Post by Mark S. Miller

Thanks Mark! This is a wonder and laughter is the best medicine. Does
this mean a distributed system could be viewed as social ecosystem? I like
that concept.

Indeed. I have written extensively on this, starting with the "Comparative
Ecology" paper at <http://e-drexler.com/p/04/03/0321miller1988b.html>.
See also section 4.2 of my thesis.

Looking again, just the last three paragraphs of Section 4.2, which are
short enough for me to paste here:


Our explanation of object programming owes a debt to the
plan-coordination literature in economics. Our explanation of encapsulation
derives in part from Friedrich Hayek’s explanation of the plan-separation
function of property rights [Hay37, Hay45, MD88]. Division of the society’s
resources among the active entities enables the decentralized formulation
of plans, based on mostly non-conflicting assumptions about what resources
will be at each plan’s disposal.

Our explanation of abstraction boundaries derives in part from Ludwig
Lachman’s explanations of the plan coordinating function of institutions
[Lac56, TM06]. The concept of “post office” stands between all the reasons
why people may want to mail a letter and all the means by which delivery
services may convey letters to their destinations. The abstraction boundary
both separates these plans from one another’s details, and it provides for
interactions so they can usefully coordinate.

Our explanation of composition derives in part from Mark Granovetter’s
visual explanations of social connectivity dynamics [Gra73, MMF00], where
new relationships form as people introduce people they know to each other.
With Granovetter’s permission, we refer to Figure 4.1 and similar diagrams
as “Granovetter diagrams.”

Post by Mark S. Miller
(Best read after rereading Chapter 4 "Programs as Plans".)

Still true. Please do look at Chapter 4.

Post by Mark S. Miller

So where are the concepts of humor and laughter in distributed systems?

On that one, I'm at a loss ;).

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark S. Miller]

I had not realized I had posed such a challenging situation. In mulling
over what needs to happen, I think the followOn message send (#hashCode)
needs to be a 3-vat situation, *of the Resolver*, to prevent GC. Here
are the steps I think are needed, #6 being the point where my system is
failing, due to its absence?

Hi Rob, I don't think I understand the scenario that's driving this. I went
back to the beginning of the thread and found

I am stuck, both conceptually, as well as understanding code I wrote a
long while ago. I was hoping to gain a little insight from the list of the
insides of resolution redirection in the 3-way case. The recent change I
have made results from my thinking I finally understand the ordering that
MirandaMethods ensure. I made changes such that a whenMoreResolved
directly follows the message that generates is by adding to the front of
the msg queue.
In the 3-way case, Carol is sending a message to Alice, passing Bob.
Alice receives the message and executes, which sends a message to Bob, then
returns the result to Carol. In Alice's vat, the DelayedRedirector is
resolved to the RemotePromise of the call to Bob, the return of Alice's
computation and I think it sends whenMoreResolved to the proxy of the new
promise resolver of the send to Bob. What little tracing I have I am
posting below, as well as the DelayedRedirector value() and the
ProxyResolver resolve() code, at the bottom. However, this is my question,
what should the redirector do in Alice's Vat to propagate the resolution
from Bob, back to Carol?
Thank you,
- Robert
// 1) getTheAnswer, which returns 42,
// 2) *hashCode, again 42* and
// 3) *whenMoreResolved*, to forward to the redirector back in Alice.

which still seems to start in the middle, or I may be misunderstanding.
What does the user code do, in what initial conditions, that set the rest
of this scenario in motion?

1. Carol sends #redirectForTheAnswer to Alice::GalaxyObject with a ref
to Bob::GalaxyObject, returning a RemotePromise1
2. Carol sends #hashCode to the RemotePromise1 from the first send,
which forwards to the Promise in Alice, where it is queued.
3. 3-way: Carol sends a ProvideFor to Bob and Alice sends an
AcceptFrom to Bob, so Alice resolves Bob::GalaxyObject.
4. Alice::GalaxyObject, under computation of #redirectForTheAnswer,
sends #getTheAnswer to Bob::GalaxyObject, returning a RemotePromise2, in
Alice, from #redirectForTheAnswer.
5. The pending #hashCode send is sent to the RemothePromise2, in
Alice, which points to Bob.
6. 3-way: In Alice, the redirected #hashCode ought to become a 3-way
for the Resolver in Carol, for the intial #hashCode send. Alice would send
a ProvideFor to Carol, for that Resolver and Bob would send an AcceptFrom
to Carol to gain a FarRef to the Resolver.
7. Bob::GalaxyObject, under computation of #hashCode, returns the
value 42.
8. Bob sends the pending #hashCode to 42, and resolves the gift
Resolver.
I believe the tricky thing is that it is the Resolver which is gifted, so
it's a different export "polarization" of the minigraph for a remote send
that has been forwarded.
Thank you,
Robert

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark S. Miller]

Hi Rob, just letting you know that it will be a few days till I can get
back to this. I'm currently in the middle of a realtime situation.

Post by Mark S. Miller

I had not realized I had posed such a challenging situation. In mulling
over what needs to happen, I think the followOn message send (#hashCode)
needs to be a 3-vat situation, *of the Resolver*, to prevent GC. Here
are the steps I think are needed, #6 being the point where my system is
failing, due to its absence?

Hi Rob, I don't think I understand the scenario that's driving this. I
went back to the beginning of the thread and found
Hi Mark, I suppose it is best to just post the pertinent code. First is
public class GalaxyObject {
public int getTheAnswer() { return 42; }
public Ref redirectForTheAnswer(Ref ref) throws NotResolvedException {
return ref.redirectMessage("getTheAnswer"); }
}
Hi Mark, does this make sense? redirectForTheAnswer sends getTheAnswer to
the arg Ref and returns the promise. In the code below, the arg Ref is
Bob, a GalazyObject in a third Vat, so the return of redirectForTheAnswer
is a RemotePromise. THe follow on message below is #hashCode, is sent to
this RemotePromise.
Ref answer = alice.redirectMessage("redirectForTheAnswer",
bob).redirectMessage("hashCode");
- Robert

I am stuck, both conceptually, as well as understanding code I wrote a
long while ago. I was hoping to gain a little insight from the list of the
insides of resolution redirection in the 3-way case. The recent change I
have made results from my thinking I finally understand the ordering that
MirandaMethods ensure. I made changes such that a whenMoreResolved
directly follows the message that generates is by adding to the front of
the msg queue.
In the 3-way case, Carol is sending a message to Alice, passing Bob.
Alice receives the message and executes, which sends a message to Bob, then
returns the result to Carol. In Alice's vat, the DelayedRedirector is
resolved to the RemotePromise of the call to Bob, the return of Alice's
computation and I think it sends whenMoreResolved to the proxy of the new
promise resolver of the send to Bob. What little tracing I have I am
posting below, as well as the DelayedRedirector value() and the
ProxyResolver resolve() code, at the bottom. However, this is my question,
what should the redirector do in Alice's Vat to propagate the resolution
from Bob, back to Carol?
Thank you,
- Robert
// 1) getTheAnswer, which returns 42,
// 2) *hashCode, again 42* and
// 3) *whenMoreResolved*, to forward to the redirector back in Alice.

which still seems to start in the middle, or I may be misunderstanding.
What does the user code do, in what initial conditions, that set the rest
of this scenario in motion?

1. Carol sends #redirectForTheAnswer to Alice::GalaxyObject with a
ref to Bob::GalaxyObject, returning a RemotePromise1
2. Carol sends #hashCode to the RemotePromise1 from the first send,
which forwards to the Promise in Alice, where it is queued.
3. 3-way: Carol sends a ProvideFor to Bob and Alice sends an
AcceptFrom to Bob, so Alice resolves Bob::GalaxyObject.
4. Alice::GalaxyObject, under computation of #redirectForTheAnswer,
sends #getTheAnswer to Bob::GalaxyObject, returning a RemotePromise2, in
Alice, from #redirectForTheAnswer.
5. The pending #hashCode send is sent to the RemothePromise2, in
Alice, which points to Bob.
6. 3-way: In Alice, the redirected #hashCode ought to become a 3-way
for the Resolver in Carol, for the intial #hashCode send. Alice would send
a ProvideFor to Carol, for that Resolver and Bob would send an AcceptFrom
to Carol to gain a FarRef to the Resolver.
7. Bob::GalaxyObject, under computation of #hashCode, returns the
value 42.
8. Bob sends the pending #hashCode to 42, and resolves the gift
Resolver.
I believe the tricky thing is that it is the Resolver which is gifted, so
it's a different export "polarization" of the minigraph for a remote send
that has been forwarded.
Thank you,
Robert

--
Cheers,
--MarkM
_______________________________________________
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark S. Miller]

Post by Mark S. Miller

I had not realized I had posed such a challenging situation. In mulling
over what needs to happen, I think the followOn message send (#hashCode)
needs to be a 3-vat situation, *of the Resolver*, to prevent GC. Here
are the steps I think are needed, #6 being the point where my system is
failing, due to its absence?

Hi Rob, I don't think I understand the scenario that's driving this. I
went back to the beginning of the thread and found
Hi Mark, I suppose it is best to just post the pertinent code. First is
public class GalaxyObject {
public int getTheAnswer() { return 42; }
public Ref redirectForTheAnswer(Ref ref) throws NotResolvedException {
return ref.redirectMessage("getTheAnswer"); }
}
Hi Mark, does this make sense? redirectForTheAnswer sends getTheAnswer to
the arg Ref and returns the promise. In the code below, the arg Ref is
Bob, a GalazyObject in a third Vat, so the return of redirectForTheAnswer
is a RemotePromise. THe follow on message below is #hashCode, is sent to
this RemotePromise.
Ref answer = alice.redirectMessage("redirectForTheAnswer",
bob).redirectMessage("hashCode");
Thanks Rob,

I am able to follow this. As I started going through your scenario below, I
started thinking "wait, I don't *think* that's right". I think of the
evolution of distributed CapTP state very much using pictures, and found
myself wanting to draw some. For this kind of thing I find slide-by-slide
"animations" to show the dynamics is good. In terms of the colors and
symbology of <http://erights.org/elib/distrib/captp/4tables.html>, would
you say that the first (and only at this moment) slide of <
https://docs.google.com/presentation/d/1VTMuCVZDPAI1f2aezDEeRUVFUygRroiZcJG6ECKp8Nw/edit#slide=id.g8da6f1810_00>
accurately reflects the initial conditions you have in mind, where Carol
has obtain live references for Alice and Bob, which has quiesced into
export/import far references?

If so, I'll proceed to illustrate how I think the scenario should go, and
then compare to your's. (Especially when I'm rusty, I need pictures in
order to think clearly.)


In answer to a previous question, the step where 2-vat interactions become
3-vat interactions is makeEventualDesc at <
https://github.com/tooantuh/pauwau/blob/master/e-jsrc/net/captp/jcomm/CapTPConnection.java#L504>.
In the upcoming initial message from Carol to Alice with Bob as argument,
a', while encoding a message for Alice, asks itself to encode b' using this
function. It sees that it has a handler for this comm system, so it is a
remote reference. It then checks whether it is a remote reference with the
same connection. In this case it is not. Therefore it is a reference to a
third vat (Vat2), so it calls new3Desc to do the rest of the work.

I think it corresponds to your steps #1 and #3, which I have yet to
illustrate. Does this seem right?

Post by Mark S. Miller
- Robert

I am stuck, both conceptually, as well as understanding code I wrote a
long while ago. I was hoping to gain a little insight from the list of the
insides of resolution redirection in the 3-way case. The recent change I
have made results from my thinking I finally understand the ordering that
MirandaMethods ensure. I made changes such that a whenMoreResolved
directly follows the message that generates is by adding to the front of
the msg queue.
In the 3-way case, Carol is sending a message to Alice, passing Bob.
Alice receives the message and executes, which sends a message to Bob, then
returns the result to Carol. In Alice's vat, the DelayedRedirector is
resolved to the RemotePromise of the call to Bob, the return of Alice's
computation and I think it sends whenMoreResolved to the proxy of the new
promise resolver of the send to Bob. What little tracing I have I am
posting below, as well as the DelayedRedirector value() and the
ProxyResolver resolve() code, at the bottom. However, this is my question,
what should the redirector do in Alice's Vat to propagate the resolution
from Bob, back to Carol?
Thank you,
- Robert
// 1) getTheAnswer, which returns 42,
// 2) *hashCode, again 42* and
// 3) *whenMoreResolved*, to forward to the redirector back in Alice.

which still seems to start in the middle, or I may be misunderstanding.
What does the user code do, in what initial conditions, that set the rest
of this scenario in motion?

1. Carol sends #redirectForTheAnswer to Alice::GalaxyObject with a
ref to Bob::GalaxyObject, returning a RemotePromise1
2. Carol sends #hashCode to the RemotePromise1 from the first send,
which forwards to the Promise in Alice, where it is queued.
3. 3-way: Carol sends a ProvideFor to Bob and Alice sends an
AcceptFrom to Bob, so Alice resolves Bob::GalaxyObject.
4. Alice::GalaxyObject, under computation of #redirectForTheAnswer,
sends #getTheAnswer to Bob::GalaxyObject, returning a RemotePromise2, in
Alice, from #redirectForTheAnswer.
5. The pending #hashCode send is sent to the RemothePromise2, in
Alice, which points to Bob.
6. 3-way: In Alice, the redirected #hashCode ought to become a 3-way
for the Resolver in Carol, for the intial #hashCode send. Alice would send
a ProvideFor to Carol, for that Resolver and Bob would send an AcceptFrom
to Carol to gain a FarRef to the Resolver.
7. Bob::GalaxyObject, under computation of #hashCode, returns the
value 42.
8. Bob sends the pending #hashCode to 42, and resolves the gift
Resolver.
I believe the tricky thing is that it is the Resolver which is gifted, so
it's a different export "polarization" of the minigraph for a remote send
that has been forwarded.
Thank you,
Robert

--
Cheers,
--MarkM
_______________________________________________
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark S. Miller]

Hi Rob,

Please look again at the slides together the notes section below each slide
where I explain what shortcuts I'm taking.


1) Are the slides accurate up to this point in the scenario (slide 8)?

2) Might any of the shortcuts I'm taking affect the issues we're trying to
investigate?


In separate news. When I went into the email archive, I found that messages
from you, like <
http://www.eros-os.org/pipermail/e-lang/2015-March/014176.html>, seem to
have the text buried within the scrubbed html attachment but are not
otherwise visible.

[Rob Withers]

Hi Mark,

Thank You! I'll comment on a few slides, relating to my implementation
or my having forgotten the symbol notation.

Slide 1: Each side of a connection in my comm system uses a Scope object
as a focal point for inter-object marshalling and tables. I do have one
NonceLocator and one set of CommTables (imports/exports,
questions/answers) and one set of gift tables per Scope. There is one
SwissTable per Vat.

Slides 6 and 7: Both of these slides have symbols that escape my
recollection. IIRC, the large burgundy triangle is a ProxyResolver, the
yellow diamond is a DelayedRedirector. What is the small blue arrow in
the intervat space? I believe it is a whenMoreResolved message that
carries a farRef to the redirector. This is a point of confusion for me.

Slide 7: when the acceptFrom completes, the result is in the exports
table of Vat2 pointed by the imports table of Vat1. The RemotePromise
that was in the questions table has been cleaned up with a GCQuestion
message, while the redirector in the exports <- imports is decremented
for reuse.

slide 8: This completes step 3 in my list.

I am not sure if the vine details will be important to see, when the
follow on message appears.

Regarding my posts, I've turned off HTML emails.

Thank you,
Rob

Post by Mark Miller
Hi Rob,
Please look again at the slides together the notes section below each
slide where I explain what shortcuts I'm taking.
1) Are the slides accurate up to this point in the scenario (slide 8)?
2) Might any of the shortcuts I'm taking affect the issues we're trying
to investigate?
In separate news. When I went into the email archive, I found that
messages from you, like
<http://www.eros-os.org/pipermail/e-lang/2015-March/014176.html>, seem
to have the text buried within the scrubbed html attachment but are not
otherwise visible.
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark S. Miller]

Post by Mark S. Miller
Hi Mark,
Thank You! I'll comment on a few slides, relating to my implementation or
my having forgotten the symbol notation.
Slide 1: Each side of a connection in my comm system uses a Scope object
as a focal point for inter-object marshalling and tables. I do have one
NonceLocator and one set of CommTables (imports/exports, questions/answers)
and one set of gift tables per Scope. There is one SwissTable per Vat.

Possible modulo renaming, this seems compatible with what is shown and
explained.

Post by Mark S. Miller
Slides 6 and 7: Both of these slides have symbols that escape my
recollection. IIRC, the large burgundy triangle is a ProxyResolver,

In using different software, I unintentionally deviated from the color
scheme in http://erights.org/elib/distrib/captp/4tables.html . In the
presentation, burgundy is the questions-table color. The r1' burgundy
triangle is an unresolved remote promise entered into Vat3's questions
table for its connection to Vat1.

Likewise on slide 7, the b' burgundy triangle in Vat3's unresolved remote
promise question for the result of the acceptFrom, whose answer will be Bob.

Post by Mark S. Miller
the yellow diamond is a DelayedRedirector.

Yes, as in http://erights.org/elib/distrib/captp/DeliverOp.html#step7 .

Post by Mark S. Miller
What is the small blue arrow in the intervat space?

As in http://erights.org/elib/distrib/captp/DeliverOp.html#step2 , it is
the implicit whenMoreResolved message, implicitly packaged together in the
DeliverOp.

Post by Mark S. Miller
I believe it is a whenMoreResolved message that carries a farRef to the
redirector.

Yes. On slide 7, as on
http://erights.org/elib/distrib/captp/DeliverOp.html#step3 , the DeliverOp
gets unserialized into both the message to be delivered to Alice (or Bob,
respectively), and the whenMoreResolved message to be delivered to the
result of that message.

Post by Mark S. Miller
This is a point of confusion for me.

Once these whenMoreResolved messages hit the 3-vat cases, in future slides,
it will gat even more confusing -- sorry. I suspect this will be where we
will find our problem.

Post by Mark S. Miller
Slide 7: when the acceptFrom completes, the result is in the exports table
of Vat2 pointed by the imports table of Vat1.

Yes.

Post by Mark S. Miller
The RemotePromise that was in the questions table has been cleaned up with
a GCQuestion message, while the redirector in the exports <- imports is
decremented for reuse.
slide 8: This completes step 3 in my list.

Excellent.

Post by Mark S. Miller
I am not sure if the vine details will be important to see, when the
follow on message appears.
Regarding my posts, I've turned off HTML emails.

Thanks. http://www.eros-os.org/pipermail/e-lang/2015-March/014186.html
looks fine.

I'm about to be traveling and will return April 1. I don't know how much
time I'll have during my travels to add additional slides.

Post by Mark S. Miller
Thank you,
Rob

Post by Mark Miller
Hi Rob,
Please look again at the slides together the notes section below each
slide where I explain what shortcuts I'm taking.
1) Are the slides accurate up to this point in the scenario (slide 8)?
2) Might any of the shortcuts I'm taking affect the issues we're trying
to investigate?
In separate news. When I went into the email archive, I found that
messages from you, like
<http://www.eros-os.org/pipermail/e-lang/2015-March/014176.html>, seem
to have the text buried within the scrubbed html attachment but are not
otherwise visible.

[Mark Miller]

Hi Rob, thanks for adding slides. I can now spot the problem -- on your
transition from slide 15 to 16.

The little blue __whenMoreResolved messages shown do not pass through the
remote promise in Vat1 on the way to the target in Vat2. Rather, as coded at
<
https://github.com/tooantuh/pauwau/blob/f8a49b417a3866b2a3fe9870cc3db82eecf596e0/e-jsrc/net/captp/jcomm/RemoteHandler.java#L139>

when a remote reference (either far ref or remote promise) receives a
__whenMoreResolved(reactor) message, where the reactor is a remote
reference (either far ref or remote promise) to a third vat, the receiving
remote reference acts like a local non-promise -- sending itself to the
reactor. This is needed for shortening, and is why the message is called
__whenMoreResolved rather than __whenResolved.

[Mark Miller]

Sorry, I don't know if it is *the* problem in the sense of explaining all
the anomalies. But it is certainly a problem.

Post by Mark Miller
Hi Rob, thanks for adding slides. I can now spot the problem -- on your
transition from slide 15 to 16.
The little blue __whenMoreResolved messages shown do not pass through the
remote promise in Vat1 on the way to the target in Vat2. Rather, as coded at
<
https://github.com/tooantuh/pauwau/blob/f8a49b417a3866b2a3fe9870cc3db82eecf596e0/e-jsrc/net/captp/jcomm/RemoteHandler.java#L139>
when a remote reference (either far ref or remote promise) receives a
__whenMoreResolved(reactor) message, where the reactor is a remote
reference (either far ref or remote promise) to a third vat, the receiving
remote reference acts like a local non-promise -- sending itself to the
reactor. This is needed for shortening, and is why the message is called
__whenMoreResolved rather than __whenResolved.

[Rob Withers]

Hi Mark, please excuse the delay. Among other distractions, I refactored
my session layer's use of crypto algorithms and added bouncy castle to
gain AES. This broke much and I have been trying to recover, with mixed
results. Currently, my 3-vat test is still failing so I am unable to
reproduce this situation, but I wanted to respond.

I think the core issue is that I am not familiar with this notation. I
looked at my code and I have the same code:
https://github.com/tooantuh/pauwau/blob/master/src/main/java/cc/ganymede/pauwau/presentation/lib/handlers/RemoteHandler.java#L133.
How should this be notated?

Thank you,
Robert

Post by Mark Miller
Hi Rob, thanks for adding slides. I can now spot the problem -- on your
transition from slide 15 to 16.
The little blue __whenMoreResolved messages shown do not pass through
the remote promise in Vat1 on the way to the target in Vat2. Rather, as
coded at
<https://github.com/tooantuh/pauwau/blob/f8a49b417a3866b2a3fe9870cc3db82eecf596e0/e-jsrc/net/captp/jcomm/RemoteHandler.java#L139>
when a remote reference (either far ref or remote promise) receives a
__whenMoreResolved(reactor) message, where the reactor is a remote
reference (either far ref or remote promise) to a third vat, the
receiving remote reference acts like a local non-promise -- sending
itself to the reactor. This is needed for shortening, and is why the
message is called __whenMoreResolved rather than __whenResolved.
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark Miller]

Post by Rob Withers
Hi Mark, please excuse the delay. Among other distractions, I refactored
my session layer's use of crypto algorithms and added bouncy castle to gain
AES. This broke much and I have been trying to recover, with mixed
results. Currently, my 3-vat test is still failing so I am unable to
reproduce this situation, but I wanted to respond.
I think the core issue is that I am not familiar with this notation. I
looked at my code and I have the same code: https://github.com/tooantuh/
pauwau/blob/master/src/main/java/cc/ganymede/pauwau/
presentation/lib/handlers/RemoteHandler.java#L133. How should this be
notated?

See slides 1-27 at <
https://docs.google.com/presentation/d/1FWcSJfZITITckrXyfihpuPnX5xf0e4kOhCnsoRFyLfI/edit?usp=sharing>
.

This is a revised version of the previous document, but I'm still one slide
short of catching up to where the previous document was -- hence the drafty
state of slides 28 and 29 which you can ignore.

Post by Rob Withers
Thank you,
Robert

Post by Mark Miller
Hi Rob, thanks for adding slides. I can now spot the problem -- on your
transition from slide 15 to 16.
The little blue __whenMoreResolved messages shown do not pass through
the remote promise in Vat1 on the way to the target in Vat2. Rather, as
coded at
<https://github.com/tooantuh/pauwau/blob/f8a49b417a3866b2a3fe9870cc3db8
2eecf596e0/e-jsrc/net/captp/jcomm/RemoteHandler.java#L139>
when a remote reference (either far ref or remote promise) receives a
__whenMoreResolved(reactor) message, where the reactor is a remote
reference (either far ref or remote promise) to a third vat, the
receiving remote reference acts like a local non-promise -- sending
itself to the reactor. This is needed for shortening, and is why the
message is called __whenMoreResolved rather than __whenResolved.
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang
_______________________________________________

e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark Miller]

Post by Mark Miller

Post by Rob Withers
Hi Mark, please excuse the delay. Among other distractions, I refactored
my session layer's use of crypto algorithms and added bouncy castle to gain
AES. This broke much and I have been trying to recover, with mixed
results. Currently, my 3-vat test is still failing so I am unable to
reproduce this situation, but I wanted to respond.
I think the core issue is that I am not familiar with this notation. I
looked at my code and I have the same code: https://github.com/tooantuh/
pauwau/blob/master/src/main/java/cc/ganymede/pauwau/
presentation/lib/handlers/RemoteHandler.java#L133. How should this be
notated?

See slides 1-27 at <
https://docs.google.com/presentation/d/1FWcSJfZITITckrXyfihpuPnX5xf0e4kOhCnsoRFyLfI/edit?usp=sharing>
.
This is a revised version of the previous document, but I'm still one
slide short of catching up to where the previous document was -- hence the
drafty state of slides 28 and 29 which you can ignore.

The new slides 26 through 29 (the current end) should complete the story so
far. Everything up to the processing of the "ga" (getAnswer) message by Bob
has quiesced. All garbage is collected. The grey objects and references on
slide 28 are not garbage, but are clearly irrelevant, and so have been
removed on slide 29.

Do all these slides make sense in their current state? Does it agree or
differ from what you think your code does or should be doing? Does it
indeed represent the maximally quiesced state prior to the delivery of "ga"
to Bob?

[Rob Withers]

_______________________________________________
e-lang mailing list
e-***@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark S. Miller]

Note that this is an old message that may be redundant with other messages
from around the same time. I do not know why this one was stuck in the
moderator queue or why I had not noticed it till now. I did just notice it
and release it. Sorry for the temporal confusion.

I truly hope not, Mark. I have this tendency to explicitly burn bridges
when I perceive they are burned, to clarify and out of frustration that I
keep bouncing. My apologies for that as it helps no one, as well as my
lack of patience for a response. I had not realized I had posted such a
challenging question.
In consideration, if I may suggest the following.
1. Carol sends to Alice with a ref to Bob and Alice redirects a call
to Bob, returning a RemotePromise both in Carol and in Alice.
2. 3-way: Carol sends a provideFor to Bob and Alice sends an
AcceptFrom to Bob.
3. Carol sends a followOn to Alice's first resolution, which is a
RemotePromise to Bob, so this flows to Bob.
4. 3-way: In Alice, the followOn should become a 3-way to the followOn
Resolver in Carol. So Alice would send a provideFor to Carol and Bob would
send an AcceptFrom to Carol and send the result of the followOn to the gift
resolver in Carol.
I think I am saying this the way I am thinking it.
Thank you.
Wait wait apologies! You did nothing at all to offend! Really!
I was just saying to a current houseguest last night, as close as I can
"Have you seen the question Rob Withers has asked lately on e-lang about
captp? It relates to race conditions and GC, but I haven't yet been able to
reload enough context to think about it. Could you have a look?" We then
went off on a long discussion on race conditions in captp-like systems x gc
x partition x malice, how difficult it is to do a full case analysis of the
cross product by hand, and how much automated tools could help. Sadly, we
did not get back to the subject of your question.
True story. I am posting this without first checking with the houseguest,
which is why I'm omitting their name.
I should have said something to explain my lack of response. The rudeness
really is mine.

Thanks for all the reticent help over the years, everyone. It's been
fun. Such a pity that that help seems permanently revoked, like an
untrusted capability. I must not have participated well in the social
context, but that is par for the course for folks with Aspergers, I am
learning. I just can't ever seem to say the right thing and more often
than not, I piss people off. The issue is I truly just don't get it.
Best regards,
Robert
Might someone be able to comment on this, please? It would help me a
great deal. I do not think it is the unimplemented far3Desc situation.
Thanks,
Robert
I see. Could you comment on how a Vine (and promise3Desc/far3Desc) get
introduced into the machinery when a followOn msg gets forwarded to a third
vat? In my example, redirectForTheAnswer sends getTheAnswer to Bob and
returns a RemotePromise, which receives a hashCode followOn msg, forwarded
to Bob.
- Robert
No, the 2-vat interactions never use, or engage in any way with, vines,
promise3Desc or far3Desc.
On Sun, Mar 1, 2015 at 9:37 AM, Robert Withers <

Post by Robert Withers
I have a question about elib. Do you use promise3Desc and far3Desc for
2-vat interactions such that a vine is always in play in any interaction?
- Robert
Mark, your instincts were right on, it seems. I have an issue with my
use of the Vine and on reflection it makes perfect sense. I am bending the
send from Carol to Alice over to Bob, so as it is a 3-way interaction, I
need a Vine. In analyzing ELib code, you have 9 references to the Vine's
constructor, while I only have 7 (minus an extra unused constructor I
have). It is going to require some digging to unearth what I am missing,
but the direction is clear. The place it blows up is in my
ProxyResolver.resolve() method, as the WeakReference has lost the ref.
However, this is not where the reference is maintained. I suspect it may
be a lack of an IdentityManager.
I republished my code to: https://github.com/tooantuh/pauwau. The
tests pass, though there is an issue with the RefTests and
TestPauwau2VatException, as well as this issue affecting
TestPauwau3VatFollowOnSend. Additionally, the presentation tests need to
be run one at a time as stopping and starting the Introducers can step on
each other.
thank you,
Robert
Have you looked at the Vine? Search for "Vine" at
http://erights.org/elib/distrib/captp/index.html
and in the source code of https://code.google.com/p/caja-captp/
I don't quite understand your question, so I'm not sure if this is even
relevant to the answer. Is it?

I found some more info: it looks as if the Ref in Alice's ProxyResolver
is being GCed, before resolution from Bob. This is specific to my
machinery, but knowing how Elib maintains a reference to the Ref, in this
case, may help make mine better. How does Elib handle this?
Thank you,
- Robert
I am stuck, both conceptually, as well as understanding code I wrote a
long while ago. I was hoping to gain a little insight from the list of the
insides of resolution redirection in the 3-way case. The recent change I
have made results from my thinking I finally understand the ordering that
MirandaMethods ensure. I made changes such that a whenMoreResolved
directly follows the message that generates is by adding to the front of
the msg queue.
In the 3-way case, Carol is sending a message to Alice, passing Bob.
Alice receives the message and executes, which sends a message to Bob, then
returns the result to Carol. In Alice's vat, the DelayedRedirector is
resolved to the RemotePromise of the call to Bob, the return of Alice's
computation and I think it sends whenMoreResolved to the proxy of the new
promise resolver of the send to Bob. What little tracing I have I am
posting below, as well as the DelayedRedirector value() and the
ProxyResolver resolve() code, at the bottom. However, this is my question,
what should the redirector do in Alice's Vat to propagate the resolution
from Bob, back to Carol?
Thank you,
- Robert
// 1) getTheAnswer, which returns 42,
// 2) *hashCode, again 42* and
// 3) *whenMoreResolved*, to forward to the redirector back in Alice.
0 [main] INFO cc.ganymede.pauwau.presentation.AbstractPauwauTest - 3
Introducers starting
549 [main] INFO cc.ganymede.pauwau.presentation.AbstractPauwauTest - 3
Introducers on the air
4553 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[497273074681788564315291637588644948944089734358])
4952 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[497273074681788564315291637588644948944089734358])
4958 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[NearRefImpl(hash: 109537538, receiver: TestObject)])
4998 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[FarRefImpl(hash: 68783569)])
5353 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[-686254831702855955980329529540587585277617841038])
5593 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[-686254831702855955980329529540587585277617841038])
5593 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[NearRefImpl(hash: 1530099003, receiver: TestObject)])
6201 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -1 answerId: -2 resolverId: -2
action: redirectForTheAnswer args: [RemotePromiseRefImpl(hash: 1034568234)])
6203 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -2 resolverId: -2
[-568687285196004884954480990488973591228663758441,
RemotePromiseRefImpl(hash: 1034568234),
-676914875674370369045480105305401075435688776666])
6239 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -2 answerId: -3 resolverId: -3
action: hashCode args: [])
6255 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
1530099003, receiver: TestObject),
-676914875674370369045480105305401075435688776666])
6259 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
6403 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[HouseAtreides:10003/-687934017861573292334955567350102524989066643525,
-676914875674370369045480105305401075435688776666,
6410 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
598908224)])
6411 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
null action: hashCode args: [])
6411 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
-2 action: getTheAnswer args: [])
6412 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
-3 action: hashCode args: [])
6412 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
whenMoreResolved args: [RedirectorProxy: FarRefImpl(hash: 177595052)])
6766 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[HouseAtreides:10003/-687934017861573292334955567350102524989066643525,
690984748)])
6767 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
null action: getTheAnswer args: [])
6767 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
null action: hashCode args: [])
6767 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
RedirectorProxy: FarRefImpl(hash: 196981675))])
6768 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[NearRefImpl(hash: 1530099003, receiver: TestObject)])
6769 [second-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[NearRefImpl(hash: 790206055, receiver: 42)])
*6770 [second-vat] DEBUG
878991039, receiver: 42)])*
*6771 [second-vat] DEBUG
790206055, receiver: 42)])*
6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[FarRefImpl(hash: 1332394016)])
6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[42])
*6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[42])*
*6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[42])*
6806 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[42])
19932 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: GCAnswerMessage(answerId: -1)
19934 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: GCAnswerMessage(answerId: -2)
19934 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: GCAnswerMessage(answerId: -3)
19984 [second-vat] DEBUG
GCAnswerMessage(answerId: -1)
19984 [second-vat] DEBUG
GCAnswerMessage(answerId: -2)
19985 [second-vat] DEBUG
GCAnswerMessage(answerId: -3)
29679 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: GCAnswerMessage(answerId: -1)
29680 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[FarRefImpl(hash: 734824022)])
29680 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[FarRefImpl(hash: 1223086084)])
29680 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[42])
29681 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: GCAnswerMessage(answerId: -1)
29681 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: GCAnswerMessage(answerId: -2)
29682 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: GCAnswerMessage(answerId: -2)
29722 [second-vat] DEBUG
GCAnswerMessage(answerId: -1)
29722 [second-vat] DEBUG
GCAnswerMessage(answerId: -2)
29726 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- receiving message: GCAnswerMessage(answerId: -1)
29726 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- receiving message: GCAnswerMessage(answerId: -2)
*// DelayedRedirector code:*
public void value(Object obj) throws NotResolvedException {
if(resolver == null)
return;
if(resolver.isFresh()) {
resolver.resolve(obj);
resolver = null;
return;
}
if(RefUtil.isLocal(obj)) {
resolver.resolve(obj);
resolver = null;
return;
}
Ref ref = (Ref)RefUtil.wrap(obj, resolver.handler.getVat());
boolean isLocalToResolverScope = false;
try {
isLocalToResolverScope =
RefUtil.isLocalToScope(resolver.handler.scope, ref);
if(isLocalToResolverScope) {
resolver.resolve(obj);
resolver = null;
return;
}
} catch (Exception e) {
reactToLostClient(e);
}
Pair<PromiseRefImpl, Resolver> pair =
RefUtil.promise(ref.getVat());
Redirector redirector = new Redirector((ProxyResolver)
pair.second());
resolver.getProxy().whenResolved(redirector);
resolver.resolve(pair.first());
resolver = null;
}
*// ProxyResolver code:*
public void resolve(final Object result) throws
NotResolvedException {
handler.scope.getVat().sendRunnable(new Runnable() {
public void run() {
if(ref == null)
return;
if(ref.get() == null)
return;
if(Exception.class.isAssignableFrom(result.getClass())) {
}
Ref newRef = RefUtil.wrap(result,
handler.scope.getVat());
try {
if (newRef == null)
ref.get().getRefImpl().becomeContext(null);
else
ref.get().getRefImpl().becomeContext(newRef.getRefImpl());
if(RefUtil.isResolved(newRef.getRefImpl())) {
handler = null;
ref = null;
}
} catch (NotResolvedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}});
}
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

--
Cheers,
--MarkM
_______________________________________________
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

--
Cheers,
--MarkM
_______________________________________________
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

--
Cheers,
--MarkM
_______________________________________________
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark Miller]

Wow, that was weird. My own reply to Rob, that you should have just seen,
was also held for moderator approval, which I just approved.

Jonathan, has something changed regarding moderation policy?

Post by Mark S. Miller
Note that this is an old message that may be redundant with other messages
from around the same time. I do not know why this one was stuck in the
moderator queue or why I had not noticed it till now. I did just notice it
and release it. Sorry for the temporal confusion.

I truly hope not, Mark. I have this tendency to explicitly burn bridges
when I perceive they are burned, to clarify and out of frustration that I
keep bouncing. My apologies for that as it helps no one, as well as my
lack of patience for a response. I had not realized I had posted such a
challenging question.
In consideration, if I may suggest the following.
1. Carol sends to Alice with a ref to Bob and Alice redirects a call
to Bob, returning a RemotePromise both in Carol and in Alice.
2. 3-way: Carol sends a provideFor to Bob and Alice sends an
AcceptFrom to Bob.
3. Carol sends a followOn to Alice's first resolution, which is a
RemotePromise to Bob, so this flows to Bob.
4. 3-way: In Alice, the followOn should become a 3-way to the
followOn Resolver in Carol. So Alice would send a provideFor to Carol and
Bob would send an AcceptFrom to Carol and send the result of the followOn
to the gift resolver in Carol.
I think I am saying this the way I am thinking it.
Thank you.
Wait wait apologies! You did nothing at all to offend! Really!
I was just saying to a current houseguest last night, as close as I can
"Have you seen the question Rob Withers has asked lately on e-lang about
captp? It relates to race conditions and GC, but I haven't yet been able to
reload enough context to think about it. Could you have a look?" We then
went off on a long discussion on race conditions in captp-like systems x gc
x partition x malice, how difficult it is to do a full case analysis of the
cross product by hand, and how much automated tools could help. Sadly, we
did not get back to the subject of your question.
True story. I am posting this without first checking with the houseguest,
which is why I'm omitting their name.
I should have said something to explain my lack of response. The rudeness
really is mine.

Thanks for all the reticent help over the years, everyone. It's been
fun. Such a pity that that help seems permanently revoked, like an
untrusted capability. I must not have participated well in the social
context, but that is par for the course for folks with Aspergers, I am
learning. I just can't ever seem to say the right thing and more often
than not, I piss people off. The issue is I truly just don't get it.
Best regards,
Robert
Might someone be able to comment on this, please? It would help me a
great deal. I do not think it is the unimplemented far3Desc situation.
Thanks,
Robert
I see. Could you comment on how a Vine (and promise3Desc/far3Desc) get
introduced into the machinery when a followOn msg gets forwarded to a third
vat? In my example, redirectForTheAnswer sends getTheAnswer to Bob and
returns a RemotePromise, which receives a hashCode followOn msg, forwarded
to Bob.
- Robert
No, the 2-vat interactions never use, or engage in any way with, vines,
promise3Desc or far3Desc.
On Sun, Mar 1, 2015 at 9:37 AM, Robert Withers <

Post by Robert Withers
I have a question about elib. Do you use promise3Desc and far3Desc for
2-vat interactions such that a vine is always in play in any interaction?
- Robert
Mark, your instincts were right on, it seems. I have an issue with my
use of the Vine and on reflection it makes perfect sense. I am bending the
send from Carol to Alice over to Bob, so as it is a 3-way interaction, I
need a Vine. In analyzing ELib code, you have 9 references to the Vine's
constructor, while I only have 7 (minus an extra unused constructor I
have). It is going to require some digging to unearth what I am missing,
but the direction is clear. The place it blows up is in my
ProxyResolver.resolve() method, as the WeakReference has lost the ref.
However, this is not where the reference is maintained. I suspect it may
be a lack of an IdentityManager.
I republished my code to: https://github.com/tooantuh/pauwau. The
tests pass, though there is an issue with the RefTests and
TestPauwau2VatException, as well as this issue affecting
TestPauwau3VatFollowOnSend. Additionally, the presentation tests need to
be run one at a time as stopping and starting the Introducers can step on
each other.
thank you,
Robert
Have you looked at the Vine? Search for "Vine" at
http://erights.org/elib/distrib/captp/index.html
and in the source code of https://code.google.com/p/caja-captp/
I don't quite understand your question, so I'm not sure if this is even
relevant to the answer. Is it?
On Sun, Feb 22, 2015 at 5:51 PM, Rob Withers <

I found some more info: it looks as if the Ref in Alice's
ProxyResolver is being GCed, before resolution from Bob. This is specific
to my machinery, but knowing how Elib maintains a reference to the Ref, in
this case, may help make mine better. How does Elib handle this?
Thank you,
- Robert
I am stuck, both conceptually, as well as understanding code I wrote a
long while ago. I was hoping to gain a little insight from the list of the
insides of resolution redirection in the 3-way case. The recent change I
have made results from my thinking I finally understand the ordering that
MirandaMethods ensure. I made changes such that a whenMoreResolved
directly follows the message that generates is by adding to the front of
the msg queue.
In the 3-way case, Carol is sending a message to Alice, passing Bob.
Alice receives the message and executes, which sends a message to Bob, then
returns the result to Carol. In Alice's vat, the DelayedRedirector is
resolved to the RemotePromise of the call to Bob, the return of Alice's
computation and I think it sends whenMoreResolved to the proxy of the new
promise resolver of the send to Bob. What little tracing I have I am
posting below, as well as the DelayedRedirector value() and the
ProxyResolver resolve() code, at the bottom. However, this is my question,
what should the redirector do in Alice's Vat to propagate the resolution
from Bob, back to Carol?
Thank you,
- Robert
// 1) getTheAnswer, which returns 42,
// 2) *hashCode, again 42* and
// 3) *whenMoreResolved*, to forward to the redirector back in Alice.
0 [main] INFO cc.ganymede.pauwau.presentation.AbstractPauwauTest - 3
Introducers starting
549 [main] INFO cc.ganymede.pauwau.presentation.AbstractPauwauTest -
3 Introducers on the air
4553 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[497273074681788564315291637588644948944089734358])
4952 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[497273074681788564315291637588644948944089734358])
4958 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[NearRefImpl(hash: 109537538, receiver: TestObject)])
4998 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[FarRefImpl(hash: 68783569)])
5353 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[-686254831702855955980329529540587585277617841038])
5593 [second-vat] DEBUG
lookupSwiss args: [-686254831702855955980329529540587585277617841038])
5593 [second-vat] DEBUG
1530099003, receiver: TestObject)])
6201 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -1 answerId: -2 resolverId: -2
action: redirectForTheAnswer args: [RemotePromiseRefImpl(hash: 1034568234)])
6203 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -2 resolverId: -2
[-568687285196004884954480990488973591228663758441,
RemotePromiseRefImpl(hash: 1034568234),
-676914875674370369045480105305401075435688776666])
6239 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -2 answerId: -3 resolverId: -3
action: hashCode args: [])
6255 [second-vat] DEBUG
provideFor args: [-568687285196004884954480990488973591228663758441,
NearRefImpl(hash: 1530099003, receiver: TestObject),
-676914875674370369045480105305401075435688776666])
6259 [second-vat] DEBUG
)])
6403 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[HouseAtreides:10003/-687934017861573292334955567350102524989066643525,
-676914875674370369045480105305401075435688776666,
6410 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
598908224)])
6411 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
null action: hashCode args: [])
6411 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
-2 action: getTheAnswer args: [])
6412 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
-3 action: hashCode args: [])
6412 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
whenMoreResolved args: [RedirectorProxy: FarRefImpl(hash: 177595052)])
6766 [second-vat] DEBUG
[HouseAtreides:10003/-687934017861573292334955567350102524989066643525,
690984748)])
6767 [second-vat] DEBUG
getTheAnswer args: [])
6767 [second-vat] DEBUG
hashCode args: [])
6767 [second-vat] DEBUG
196981675))])
6768 [second-vat] DEBUG
1530099003, receiver: TestObject)])
6769 [second-vat] DEBUG
790206055, receiver: 42)])
*6770 [second-vat] DEBUG
878991039, receiver: 42)])*
*6771 [second-vat] DEBUG
790206055, receiver: 42)])*
6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[FarRefImpl(hash: 1332394016)])
6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[42])
*6805 [first-vat] DEBUG
DeliverOnlyMessage(receiverId: 4 action: value args: [42])*
*6805 [first-vat] DEBUG
DeliverOnlyMessage(receiverId: 5 action: value args: [42])*
6806 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[42])
19932 [first-vat] DEBUG
GCAnswerMessage(answerId: -1)
19934 [first-vat] DEBUG
GCAnswerMessage(answerId: -2)
19934 [first-vat] DEBUG
GCAnswerMessage(answerId: -3)
19984 [second-vat] DEBUG
GCAnswerMessage(answerId: -1)
19984 [second-vat] DEBUG
GCAnswerMessage(answerId: -2)
19985 [second-vat] DEBUG
GCAnswerMessage(answerId: -3)
29679 [third-vat] DEBUG
GCAnswerMessage(answerId: -1)
29680 [third-vat] DEBUG
734824022)])
29680 [third-vat] DEBUG
1223086084)])
29680 [third-vat] DEBUG
DeliverOnlyMessage(receiverId: 3 action: value args: [42])
29681 [third-vat] DEBUG
GCAnswerMessage(answerId: -1)
29681 [third-vat] DEBUG
GCAnswerMessage(answerId: -2)
29682 [third-vat] DEBUG
GCAnswerMessage(answerId: -2)
29722 [second-vat] DEBUG
GCAnswerMessage(answerId: -1)
29722 [second-vat] DEBUG
GCAnswerMessage(answerId: -2)
29726 [first-vat] DEBUG
GCAnswerMessage(answerId: -1)
29726 [first-vat] DEBUG
GCAnswerMessage(answerId: -2)
*// DelayedRedirector code:*
public void value(Object obj) throws NotResolvedException {
if(resolver == null)
return;
if(resolver.isFresh()) {
resolver.resolve(obj);
resolver = null;
return;
}
if(RefUtil.isLocal(obj)) {
resolver.resolve(obj);
resolver = null;
return;
}
Ref ref = (Ref)RefUtil.wrap(obj, resolver.handler.getVat());
boolean isLocalToResolverScope = false;
try {
isLocalToResolverScope =
RefUtil.isLocalToScope(resolver.handler.scope, ref);
if(isLocalToResolverScope) {
resolver.resolve(obj);
resolver = null;
return;
}
} catch (Exception e) {
reactToLostClient(e);
}
Pair<PromiseRefImpl, Resolver> pair =
RefUtil.promise(ref.getVat());
Redirector redirector = new Redirector((ProxyResolver)
pair.second());
resolver.getProxy().whenResolved(redirector);
resolver.resolve(pair.first());
resolver = null;
}
*// ProxyResolver code:*
public void resolve(final Object result) throws
NotResolvedException {
handler.scope.getVat().sendRunnable(new Runnable() {
public void run() {
if(ref == null)
return;
if(ref.get() == null)
return;
if(Exception.class.isAssignableFrom(result.getClass())) {
}
Ref newRef = RefUtil.wrap(result,
handler.scope.getVat());
try {
if (newRef == null)
ref.get().getRefImpl().becomeContext(null);
else
ref.get().getRefImpl().becomeContext(newRef.getRefImpl());
if(RefUtil.isResolved(newRef.getRefImpl())) {
handler = null;
ref = null;
}
} catch (NotResolvedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}});
}
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

--
Cheers,
--MarkM
_______________________________________________
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

--
Cheers,
--MarkM
_______________________________________________
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

--
Cheers,
--MarkM
_______________________________________________
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

--
Cheers,
--MarkM
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

[Robert Withers]

Oh Jesus, 8 months ago seems so long. I think I said it wrong because I
don't mean to do so, burn my bridges.

I have looked back at what you built, Mark, and the diagram showing this
and it's really fine. I like that it shows that temporal flow as I think
it is a unique aspect of Elib. Thank you.

Robert

Post by Mark S. Miller
Note that this is an old message that may be redundant with other
messages from around the same time. I do not know why this one was
stuck in the moderator queue or why I had not noticed it till now. I
did just notice it and release it. Sorry for the temporal confusion.
On Sat, Mar 7, 2015 at 7:28 PM, Rob Withers
I truly hope not, Mark. I have this tendency to explicitly burn
bridges when I perceive they are burned, to clarify and out of
frustration that I keep bouncing. My apologies for that as it
helps no one, as well as my lack of patience for a response. I
had not realized I had posted such a challenging question.
In consideration, if I may suggest the following.
1. Carol sends to Alice with a ref to Bob and Alice redirects a
call to Bob, returning a RemotePromise both in Carol and in Alice.
2. 3-way: Carol sends a provideFor to Bob and Alice sends an
AcceptFrom to Bob.
3. Carol sends a followOn to Alice's first resolution, which is a
RemotePromise to Bob, so this flows to Bob.
4. 3-way: In Alice, the followOn should become a 3-way to the
followOn Resolver in Carol. So Alice would send a provideFor
to Carol and Bob would send an AcceptFrom to Carol and send
the result of the followOn to the gift resolver in Carol.
I think I am saying this the way I am thinking it.
Thank you.

Post by Mark S. Miller
Wait wait apologies! You did nothing at all to offend! Really!
I was just saying to a current houseguest last night, as close as
"Have you seen the question Rob Withers has asked lately on
e-lang about captp? It relates to race conditions and GC, but I
haven't yet been able to reload enough context to think about it.
Could you have a look?" We then went off on a long discussion on
race conditions in captp-like systems x gc x partition x malice,
how difficult it is to do a full case analysis of the cross
product by hand, and how much automated tools could help. Sadly,
we did not get back to the subject of your question.
True story. I am posting this without first checking with the
houseguest, which is why I'm omitting their name.
I should have said something to explain my lack of response. The
rudeness really is mine.
On Sat, Mar 7, 2015 at 3:28 PM, Rob Withers
Thanks for all the reticent help over the years, everyone.
It's been fun. Such a pity that that help seems permanently
revoked, like an untrusted capability. I must not have
participated well in the social context, but that is par for
the course for folks with Aspergers, I am learning. I just
can't ever seem to say the right thing and more often than
not, I piss people off. The issue is I truly just don't get it.
Best regards,
Robert

Might someone be able to comment on this, please? It would
help me a great deal. I do not think it is the
unimplemented far3Desc situation.
Thanks,
Robert

I see. Could you comment on how a Vine (and
promise3Desc/far3Desc) get introduced into the machinery
when a followOn msg gets forwarded to a third vat? In my
example, redirectForTheAnswer sends getTheAnswer to Bob and
returns a RemotePromise, which receives a hashCode followOn
msg, forwarded to Bob.
- Robert

Post by Mark S. Miller
No, the 2-vat interactions never use, or engage in any way
with, vines, promise3Desc or far3Desc.
On Sun, Mar 1, 2015 at 9:37 AM, Robert Withers
I have a question about elib. Do you use promise3Desc
and far3Desc for 2-vat interactions such that a vine
is always in play in any interaction?
- Robert
Mark, your instincts were right on, it seems. I have
an issue with my use of the Vine and on reflection it
makes perfect sense. I am bending the send from Carol
to Alice over to Bob, so as it is a 3-way interaction,
I need a Vine. In analyzing ELib code, you have 9
references to the Vine's constructor, while I only
have 7 (minus an extra unused constructor I have). It
is going to require some digging to unearth what I am
missing, but the direction is clear. The place it
blows up is in my ProxyResolver.resolve() method, as
the WeakReference has lost the ref. However, this is
not where the reference is maintained. I suspect it
may be a lack of an IdentityManager.
https://github.com/tooantuh/pauwau. The tests pass,
though there is an issue with the RefTests and
TestPauwau2VatException, as well as this issue
affecting TestPauwau3VatFollowOnSend. Additionally,
the presentation tests need to be run one at a time as
stopping and starting the Introducers can step on each
other.
thank you,
Robert

Post by Mark S. Miller
Have you looked at the Vine? Search for "Vine" at
http://erights.org/elib/distrib/captp/index.html
and in the source code of
https://code.google.com/p/caja-captp/
I don't quite understand your question, so I'm not
sure if this is even relevant to the answer. Is it?
On Sun, Feb 22, 2015 at 5:51 PM, Rob Withers
I found some more info: it looks as if the Ref in
Alice's ProxyResolver is being GCed, before
resolution from Bob. This is specific to my
machinery, but knowing how Elib maintains a
reference to the Ref, in this case, may help make
mine better. How does Elib handle this?
Thank you,
- Robert

I am stuck, both conceptually, as well as
understanding code I wrote a long while ago. I
was hoping to gain a little insight from the
list of the insides of resolution redirection in
the 3-way case. The recent change I have made
results from my thinking I finally understand
the ordering that MirandaMethods ensure. I made
changes such that a whenMoreResolved directly
follows the message that generates is by adding
to the front of the msg queue.
In the 3-way case, Carol is sending a message to
Alice, passing Bob. Alice receives the message
and executes, which sends a message to Bob, then
returns the result to Carol. In Alice's vat,
the DelayedRedirector is resolved to the
RemotePromise of the call to Bob, the return of
Alice's computation and I think it sends
whenMoreResolved to the proxy of the new promise
resolver of the send to Bob. What little
tracing I have I am posting below, as well as
the DelayedRedirector value() and the
ProxyResolver resolve() code, at the bottom.
However, this is my question, what should the
redirector do in Alice's Vat to propagate the
resolution from Bob, back to Carol?
Thank you,
- Robert
// 1) getTheAnswer, which returns 42,
// 2) *hashCode, again 42* and
// 3) *whenMoreResolved*, to forward to the
redirector back in Alice.
0 [main] INFO
cc.ganymede.pauwau.presentation.AbstractPauwauTest
- 3 Introducers starting
549 [main] INFO
cc.ganymede.pauwau.presentation.AbstractPauwauTest
- 3 Introducers on the air
4553 [main] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0
answerId: -1 resolverId: -1 action: lookupSwiss
[497273074681788564315291637588644948944089734358])
4952 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: DeliverMessage(receiverId: 0
[497273074681788564315291637588644948944089734358])
4958 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
109537538, receiver: TestObject)])
4998 [third-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
DeliverOnlyMessage(receiverId: 1 action: value
args: [FarRefImpl(hash: 68783569)])
5353 [main] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0
answerId: -1 resolverId: -1 action: lookupSwiss
[-686254831702855955980329529540587585277617841038])
5593 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: DeliverMessage(receiverId: 0
[-686254831702855955980329529540587585277617841038])
5593 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
1530099003, receiver: TestObject)])
6201 [main] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -1
[RemotePromiseRefImpl(hash: 1034568234)])
6203 [main] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0
answerId: -2 resolverId: -2 action: provideFor
[-568687285196004884954480990488973591228663758441,
RemotePromiseRefImpl(hash: 1034568234),
-676914875674370369045480105305401075435688776666])
6239 [main] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -2
answerId: -3 resolverId: -3 action: hashCode
args: [])
6255 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: DeliverMessage(receiverId: 0
answerId: -2 resolverId: null action: provideFor
[-568687285196004884954480990488973591228663758441,
TestObject),
-676914875674370369045480105305401075435688776666])
6259 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
6403 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0
answerId: -1 resolverId: -1 action: acceptFrom
[HouseAtreides:10003/-687934017861573292334955567350102524989066643525,
-676914875674370369045480105305401075435688776666,
6410 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: DeliverMessage(receiverId: -1
[RemotePromiseRefImpl(hash: 598908224)])
6411 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: DeliverMessage(receiverId: -2
answerId: -3 resolverId: null action: hashCode
args: [])
6411 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -1
answerId: -2 resolverId: -2 action: getTheAnswer
args: [])
6412 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -2
answerId: -3 resolverId: -3 action: hashCode
args: [])
6412 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
[RedirectorProxy: FarRefImpl(hash: 177595052)])
6766 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: DeliverMessage(receiverId: 0
answerId: -1 resolverId: null action: acceptFrom
[HouseAtreides:10003/-687934017861573292334955567350102524989066643525,
-676914875674370369045480105305401075435688776666,
FarRefImpl(hash: 690984748)])
6767 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: DeliverMessage(receiverId: -1
getTheAnswer args: [])
6767 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: DeliverMessage(receiverId: -2
answerId: -3 resolverId: null action: hashCode
args: [])
6767 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
FarRefImpl(hash: 196981675))])
6768 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
1530099003, receiver: TestObject)])
6769 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
790206055, receiver: 42)])
*6770 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
878991039, receiver: 42)])**
**6771 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
790206055, receiver: 42)])**
*6805 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
DeliverOnlyMessage(receiverId: 2 action: value
args: [FarRefImpl(hash: 1332394016)])
6805 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
DeliverOnlyMessage(receiverId: 3 action: value
args: [42])
*6805 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
DeliverOnlyMessage(receiverId: 4 action: value
args: [42])**
**6805 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
DeliverOnlyMessage(receiverId: 5 action: value
args: [42])**
*6806 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
3 action: value args: [42])
19932 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -1)
19934 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -2)
19934 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -3)
19984 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -1)
19984 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -2)
19985 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -3)
29679 [third-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -1)
29680 [third-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
DeliverOnlyMessage(receiverId: 1 action: value
args: [FarRefImpl(hash: 734824022)])
29680 [third-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
DeliverOnlyMessage(receiverId: 2 action: value
args: [FarRefImpl(hash: 1223086084)])
29680 [third-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
DeliverOnlyMessage(receiverId: 3 action: value
args: [42])
29681 [third-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -1)
29681 [third-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -2)
29682 [third-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: GCAnswerMessage(answerId: -2)
29722 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -1)
29722 [second-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -2)
29726 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -1)
29726 [first-vat] DEBUG
cc.ganymede.pauwau.presentation.PauwauTerminal -
receiving message: GCAnswerMessage(answerId: -2)
*// DelayedRedirector code:*
public void value(Object obj) throws
NotResolvedException {
if(resolver == null)
return;
if(resolver.isFresh()) {
resolver.resolve(obj);
resolver = null;
return;
}
if(RefUtil.isLocal(obj)) {
resolver.resolve(obj);
resolver = null;
return;
}
Ref ref = (Ref)RefUtil.wrap(obj,
resolver.handler.getVat());
boolean isLocalToResolverScope = false;
try {
isLocalToResolverScope =
RefUtil.isLocalToScope(resolver.handler.scope, ref);
if(isLocalToResolverScope) {
resolver.resolve(obj);
resolver = null;
return;
}
} catch (Exception e) {
reactToLostClient(e);
}
Pair<PromiseRefImpl, Resolver> pair =
RefUtil.promise(ref.getVat());
Redirector redirector = new
Redirector((ProxyResolver) pair.second());
resolver.getProxy().whenResolved(redirector);
resolver.resolve(pair.first());
resolver = null;
}
*// ProxyResolver code:*
public void resolve(final Object result)
throws NotResolvedException {
handler.scope.getVat().sendRunnable(new Runnable() {
public void run() {
if(ref == null)
return;
if(ref.get() == null)
return;
if(Exception.class.isAssignableFrom(result.getClass()))
{
}
Ref newRef = RefUtil.wrap(result,
handler.scope.getVat());
try {
if (newRef == null)
ref.get().getRefImpl().becomeContext(null);
else
ref.get().getRefImpl().becomeContext(newRef.getRefImpl());
if(RefUtil.isResolved(newRef.getRefImpl())) {
handler = null;
ref = null;
}
} catch (NotResolvedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}});
}

_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang
--
Cheers,
--MarkM
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang
--
Cheers,
--MarkM
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang
--
Cheers,
--MarkM
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang
--
Cheers,
--MarkM

[Mark S. Miller]

Since it has been so long, as a reminder, the diagram/animation Rob refers
to is at
https://docs.google.com/presentation/d/1FWcSJfZITITckrXyfihpuPnX5xf0e4kOhCnsoRFyLfI/

Post by Robert Withers
Oh Jesus, 8 months ago seems so long. I think I said it wrong because I
don't mean to do so, burn my bridges.
I have looked back at what you built, Mark, and the diagram showing this
and it's really fine. I like that it shows that temporal flow as I think it
is a unique aspect of Elib. Thank you.
Robert
Note that this is an old message that may be redundant with other messages
from around the same time. I do not know why this one was stuck in the
moderator queue or why I had not noticed it till now. I did just notice it
and release it. Sorry for the temporal confusion.

I truly hope not, Mark. I have this tendency to explicitly burn bridges
when I perceive they are burned, to clarify and out of frustration that I
keep bouncing. My apologies for that as it helps no one, as well as my
lack of patience for a response. I had not realized I had posted such a
challenging question.
In consideration, if I may suggest the following.
1. Carol sends to Alice with a ref to Bob and Alice redirects a call
to Bob, returning a RemotePromise both in Carol and in Alice.
2. 3-way: Carol sends a provideFor to Bob and Alice sends an
AcceptFrom to Bob.
3. Carol sends a followOn to Alice's first resolution, which is a
RemotePromise to Bob, so this flows to Bob.
4. 3-way: In Alice, the followOn should become a 3-way to the
followOn Resolver in Carol. So Alice would send a provideFor to Carol and
Bob would send an AcceptFrom to Carol and send the result of the followOn
to the gift resolver in Carol.
I think I am saying this the way I am thinking it.
Thank you.
Wait wait apologies! You did nothing at all to offend! Really!
I was just saying to a current houseguest last night, as close as I can
"Have you seen the question Rob Withers has asked lately on e-lang about
captp? It relates to race conditions and GC, but I haven't yet been able to
reload enough context to think about it. Could you have a look?" We then
went off on a long discussion on race conditions in captp-like systems x gc
x partition x malice, how difficult it is to do a full case analysis of the
cross product by hand, and how much automated tools could help. Sadly, we
did not get back to the subject of your question.
True story. I am posting this without first checking with the houseguest,
which is why I'm omitting their name.
I should have said something to explain my lack of response. The rudeness
really is mine.
On Sat, Mar 7, 2015 at 3:28 PM, Rob Withers <

Thanks for all the reticent help over the years, everyone. It's been
fun. Such a pity that that help seems permanently revoked, like an
untrusted capability. I must not have participated well in the social
context, but that is par for the course for folks with Aspergers, I am
learning. I just can't ever seem to say the right thing and more often
than not, I piss people off. The issue is I truly just don't get it.
Best regards,
Robert
Might someone be able to comment on this, please? It would help me a
great deal. I do not think it is the unimplemented far3Desc situation.
Thanks,
Robert
I see. Could you comment on how a Vine (and promise3Desc/far3Desc) get
introduced into the machinery when a followOn msg gets forwarded to a third
vat? In my example, redirectForTheAnswer sends getTheAnswer to Bob and
returns a RemotePromise, which receives a hashCode followOn msg, forwarded
to Bob.
- Robert
No, the 2-vat interactions never use, or engage in any way with, vines,
promise3Desc or far3Desc.
On Sun, Mar 1, 2015 at 9:37 AM, Robert Withers <

Post by Robert Withers
I have a question about elib. Do you use promise3Desc and far3Desc for
2-vat interactions such that a vine is always in play in any interaction?
- Robert
Mark, your instincts were right on, it seems. I have an issue with my
use of the Vine and on reflection it makes perfect sense. I am bending the
send from Carol to Alice over to Bob, so as it is a 3-way interaction, I
need a Vine. In analyzing ELib code, you have 9 references to the Vine's
constructor, while I only have 7 (minus an extra unused constructor I
have). It is going to require some digging to unearth what I am missing,
but the direction is clear. The place it blows up is in my
ProxyResolver.resolve() method, as the WeakReference has lost the ref.
However, this is not where the reference is maintained. I suspect it may
be a lack of an IdentityManager.
I republished my code to: <https://github.com/tooantuh/pauwau>
https://github.com/tooantuh/pauwau. The tests pass, though there is
an issue with the RefTests and TestPauwau2VatException, as well as this
issue affecting TestPauwau3VatFollowOnSend. Additionally, the presentation
tests need to be run one at a time as stopping and starting the Introducers
can step on each other.
thank you,
Robert
Have you looked at the Vine? Search for "Vine" at
<http://erights.org/elib/distrib/captp/index.html>
http://erights.org/elib/distrib/captp/index.html
and in the source code of <https://code.google.com/p/caja-captp/>
https://code.google.com/p/caja-captp/
I don't quite understand your question, so I'm not sure if this is even
relevant to the answer. Is it?
On Sun, Feb 22, 2015 at 5:51 PM, Rob Withers <

I found some more info: it looks as if the Ref in Alice's
ProxyResolver is being GCed, before resolution from Bob. This is specific
to my machinery, but knowing how Elib maintains a reference to the Ref, in
this case, may help make mine better. How does Elib handle this?
Thank you,
- Robert
I am stuck, both conceptually, as well as understanding code I wrote a
long while ago. I was hoping to gain a little insight from the list of the
insides of resolution redirection in the 3-way case. The recent change I
have made results from my thinking I finally understand the ordering that
MirandaMethods ensure. I made changes such that a whenMoreResolved
directly follows the message that generates is by adding to the front of
the msg queue.
In the 3-way case, Carol is sending a message to Alice, passing Bob.
Alice receives the message and executes, which sends a message to Bob, then
returns the result to Carol. In Alice's vat, the DelayedRedirector is
resolved to the RemotePromise of the call to Bob, the return of Alice's
computation and I think it sends whenMoreResolved to the proxy of the new
promise resolver of the send to Bob. What little tracing I have I am
posting below, as well as the DelayedRedirector value() and the
ProxyResolver resolve() code, at the bottom. However, this is my question,
what should the redirector do in Alice's Vat to propagate the resolution
from Bob, back to Carol?
Thank you,
- Robert
// 1) getTheAnswer, which returns 42,
// 2) *hashCode, again 42* and
// 3) *whenMoreResolved*, to forward to the redirector back in Alice.
0 [main] INFO cc.ganymede.pauwau.presentation.AbstractPauwauTest - 3
Introducers starting
549 [main] INFO cc.ganymede.pauwau.presentation.AbstractPauwauTest -
3 Introducers on the air
4553 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[497273074681788564315291637588644948944089734358])
4952 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[497273074681788564315291637588644948944089734358])
4958 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[NearRefImpl(hash: 109537538, receiver: TestObject)])
4998 [third-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[FarRefImpl(hash: 68783569)])
5353 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[-686254831702855955980329529540587585277617841038])
5593 [second-vat] DEBUG
lookupSwiss args: [-686254831702855955980329529540587585277617841038])
5593 [second-vat] DEBUG
1530099003, receiver: TestObject)])
6201 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -1 answerId: -2 resolverId: -2
action: redirectForTheAnswer args: [RemotePromiseRefImpl(hash: 1034568234)])
6203 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: 0 answerId: -2 resolverId: -2
[-568687285196004884954480990488973591228663758441,
RemotePromiseRefImpl(hash: 1034568234),
-676914875674370369045480105305401075435688776666])
6239 [main] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal -
sending message: DeliverMessage(receiverId: -2 answerId: -3 resolverId: -3
action: hashCode args: [])
6255 [second-vat] DEBUG
provideFor args: [-568687285196004884954480990488973591228663758441,
NearRefImpl(hash: 1530099003, receiver: TestObject),
-676914875674370369045480105305401075435688776666])
6259 [second-vat] DEBUG
)])
6403 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
- sending message: DeliverMessage(receiverId: 0 answerId: -1 resolverId: -1
[HouseAtreides:10003/-687934017861573292334955567350102524989066643525,
-676914875674370369045480105305401075435688776666,
6410 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
598908224)])
6411 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
null action: hashCode args: [])
6411 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
-2 action: getTheAnswer args: [])
6412 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
-3 action: hashCode args: [])
6412 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
whenMoreResolved args: [RedirectorProxy: FarRefImpl(hash: 177595052)])
6766 [second-vat] DEBUG
[HouseAtreides:10003/-687934017861573292334955567350102524989066643525,
690984748)])
6767 [second-vat] DEBUG
getTheAnswer args: [])
6767 [second-vat] DEBUG
hashCode args: [])
6767 [second-vat] DEBUG
196981675))])
6768 [second-vat] DEBUG
1530099003, receiver: TestObject)])
6769 [second-vat] DEBUG
790206055, receiver: 42)])
*6770 [second-vat] DEBUG
878991039, receiver: 42)])*
*6771 [second-vat] DEBUG
790206055, receiver: 42)])*
6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[FarRefImpl(hash: 1332394016)])
6805 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[42])
*6805 [first-vat] DEBUG
DeliverOnlyMessage(receiverId: 4 action: value args: [42])*
*6805 [first-vat] DEBUG
DeliverOnlyMessage(receiverId: 5 action: value args: [42])*
6806 [first-vat] DEBUG cc.ganymede.pauwau.presentation.PauwauTerminal
[42])
19932 [first-vat] DEBUG
GCAnswerMessage(answerId: -1)
19934 [first-vat] DEBUG
GCAnswerMessage(answerId: -2)
19934 [first-vat] DEBUG
GCAnswerMessage(answerId: -3)
19984 [second-vat] DEBUG
GCAnswerMessage(answerId: -1)
19984 [second-vat] DEBUG
GCAnswerMessage(answerId: -2)
19985 [second-vat] DEBUG
GCAnswerMessage(answerId: -3)
29679 [third-vat] DEBUG
GCAnswerMessage(answerId: -1)
29680 [third-vat] DEBUG
734824022)])
29680 [third-vat] DEBUG
1223086084)])
29680 [third-vat] DEBUG
DeliverOnlyMessage(receiverId: 3 action: value args: [42])
29681 [third-vat] DEBUG
GCAnswerMessage(answerId: -1)
29681 [third-vat] DEBUG
GCAnswerMessage(answerId: -2)
29682 [third-vat] DEBUG
GCAnswerMessage(answerId: -2)
29722 [second-vat] DEBUG
GCAnswerMessage(answerId: -1)
29722 [second-vat] DEBUG
GCAnswerMessage(answerId: -2)
29726 [first-vat] DEBUG
GCAnswerMessage(answerId: -1)
29726 [first-vat] DEBUG
GCAnswerMessage(answerId: -2)
*// DelayedRedirector code:*
public void value(Object obj) throws NotResolvedException {
if(resolver == null)
return;
if(resolver.isFresh()) {
resolver.resolve(obj);
resolver = null;
return;
}
if(RefUtil.isLocal(obj)) {
resolver.resolve(obj);
resolver = null;
return;
}
Ref ref = (Ref)RefUtil.wrap(obj, resolver.handler.getVat());
boolean isLocalToResolverScope = false;
try {
isLocalToResolverScope =
RefUtil.isLocalToScope(resolver.handler.scope, ref);
if(isLocalToResolverScope) {
resolver.resolve(obj);
resolver = null;
return;
}
} catch (Exception e) {
reactToLostClient(e);
}
Pair<PromiseRefImpl, Resolver> pair =
RefUtil.promise(ref.getVat());
Redirector redirector = new Redirector((ProxyResolver)
pair.second());
resolver.getProxy().whenResolved(redirector);
resolver.resolve(pair.first());
resolver = null;
}
*// ProxyResolver code:*
public void resolve(final Object result) throws
NotResolvedException {
handler.scope.getVat().sendRunnable(new Runnable() {
public void run() {
if(ref == null)
return;
if(ref.get() == null)
return;
if(Exception.class.isAssignableFrom(result.getClass())) {
}
Ref newRef = RefUtil.wrap(result,
handler.scope.getVat());
try {
if (newRef == null)
ref.get().getRefImpl().becomeContext(null);
else
ref.get().getRefImpl().becomeContext(newRef.getRefImpl());
if(RefUtil.isResolved(newRef.getRefImpl())) {
handler = null;
ref = null;
}
} catch (NotResolvedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}});
}
_______________________________________________
e-lang mailing list
<http://www.eros-os.org/mailman/listinfo/e-lang>
http://www.eros-os.org/mailman/listinfo/e-lang

--
Cheers,
--MarkM
_______________________________________________
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

--
Cheers,
--MarkM
_______________________________________________
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

--
Cheers,
--MarkM
_______________________________________________
_______________________________________________
e-lang mailing list
http://www.eros-os.org/mailman/listinfo/e-lang

--
Cheers,
--MarkM