[e-lang] Lamport slots with PBC (please ignore duplicate msg if exists)

[Mark S. Miller]

Martin_Scheffler wrote:
> Mark S. Miller wrote:
>> What does "npbc" stand for?
>>
> Not pass by copy. The newly created slot needs to have a ref to the original
> slot. The lamportReporter is pbc, so it would be copied if I did not wrap it
> with a not-pbc object.


Ah! Lightbulb goes on, very clever!

However, I think you should do it the other way around. The object currently 
called lamportReporter should not be made pbc, and it should serve the role 
currently served by your npbc object. Instead, most places where 
lamportReporter currently escapes, such as readOnly/0, you should instead wrap 
lamportReporter with a pbc wrapper which acts as your lamportReporter 
currently acts.


> Mark S. Miller wrote:
>> How did you work around the fact that I still haven't fixed:
>> https://sourceforge.net/tracker/index.php?func=detail&aid=1635331&group_id=75274&atid=551529
>>
> With a quick and dirty hack.
> [...]
> This is ugly but now I can play around with it.

Yup, that's ugly. I'm glad to see you're proceeding by such means when you 
need to, so that you can get other things working without getting stuck. Even 
better, it's sufficiently ugly that it should help prod me to fixing this 
sooner rather than later ;).



> When I pass PBC objects between VATs, the __optUncall function is executed
> twice or more, and on the other side the constructor is called twice or
> more, too.
> This only happens when I set up inter-vat connection over a sturdy ref. When
> I spawn a vat with seedVatAuthor, everything seems to work as expected.
> Is this a bug? I have a test case if this is interesting.

I suspect this is because whenUpdated/2 eventual-sends the lamportReporter as 
an argument of an inter-vat reactToUpdate/3 message. Now that you've made 
lamportReporter pbc, passing it as a parameter over captp does more work than 
it should. In fact, I'm surprised it didn't cause an infinite regress. Within 
your current code, the fix would be to pass npbc instead. If you do pbc-ness 
the other way around, the required changes would be elsewhere.

The fact that this bug doesn't manifest under boot-comm is further evidence 
that this is indeed the problem. Boot-comm does not (yet?) recognize pbc.


> BTW, should I post bug reports here or on slashdot?

I prefer slashdot, but appreciate either. Thanks!


-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM