[crac] RFR: Fix ordering of invocation on Resources

[Anton Kozlov]

On Mon, 24 Apr 2023 08:46:50 GMT, Radim Vansa <duke at openjdk.org> wrote:

> On regular resources afterRestore is not called if the resource throws, it does not end up in the restoreQ.

I'm puzzled how this is possible in the implementation before the patch. The code says it should

        List<R> resources = checkpointQ. ... ;
        for (Resource r : resources) { ... }
        Collections.reverse(resources);
        restoreQ = resources;


We'll have to document the expected behavior, but that is another concern.

> I am a bit worried about calling R3.bC that would live in a different context when R1 is already restored.

This is a question of specification. If we set that, it will be adopted by rearranging Contextes and Resources, pretty manageable.

In general, resources should not have a lot of assumptions about other resources. Otherwise, they should directly refer to each other, rathen than relying on the Context. That will be more straightforward and less error-prone.

> What is the point of continuing with the checkpoint when we now that it won't happen in the end, with all the suppressed exceptions in the first place? Just to collect all errors at once rather than one-by-one? Is it worth potential false positives?

Correct, to run all registered code, that may also have some side-effects (unpreferable, but possible). Having that checkpoint won't happen anyway, false positive does not look a problem.

-------------

PR Review Comment: https://git.openjdk.org/crac/pull/60#discussion_r1175016444