A stab at the sealer in E
Mark S. Miller
Wed, 03 Nov 1999 14:11:03 -0800
At 12:53 PM 11/3/99 , Marc Stiegler wrote:
>Anyway, I forced myself not to read ping's solution till after I'd done my
>own, just to see how much variation there might be in the solutions.
Very good, you two. I believe both solutions are correct, once you add the
exception throw. Clients of the sealer/unsealer abstraction, like
MintMaker, depend on this exception to prevent normal control flow from
continuing past an unsuccessful unseal.
When you enhance your code to check for an unsuccessful attempt to unseal,
remember that null is a perfectly fine value to seal in an envelope. Your
code must work correctly when the payload is null.
>... I think mine might have the advantage that it is
>possible to garbage collect the messages and envelopes (though my knowledge
>of distributed garbage collection is almost nonexistent, I could easily be
>wrong). With that, here's the marcs solution:
You are correct, and your's is the first solution I've seen that doesn't
have a gc problem equivalent to Ping's. Distributed gc is irrelevant in
this example, because all the relevant objects are co-located in the same
vat. That co-location is also what makes your novel solution possible.
Because your code has mutual exclusion on all relevant state during the
unsealing attempt, it need not worry about the normal concurrency issues.
These issues prevented other solutions from using a single mutable cell per
sealer/unsealer pair. Ping's solution, like the traditional ones,
effectively uses a mutable cell per envelope (the association in the table).
When I saw your single shared cell, at first I thought "that can't possibly
work". But it does.
With your solution, it seems there is no longer any strong need for
sealer/unsealer pairs to be provided by the kernel. This is real progress!