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!
Cheers,
--MarkM