exit freezes the first value it sees

[gfldex]

Consider the following code:

   END { exit 0 }
    my atomicint $i;
    my @proms;
    for ^20 {
        @proms.push: start { exit ++⚛$i; }
    }

    await @proms;

   END { exit 1 }

Can you guess the exit code? Right now the thread that first gets to set a state container in exit wins. In the case of the END-phasers, the last registered phaser wins. If threads are involved, that may become random as well. Also, any module may add END-phasers at runtime (EVAL being evil). All this is not covered by Roast and we should warn that depending on exit is depeding on impelentation details, which may change whenever the compiler is upgrated.

[lizmat]

FWIW, it feels like a case of DIHWIDT, as you would not typically use exit in an END block, now would you? It feels like a code smell to me.

The alternative was to completely disallow exit from END blocks.

[dontlaugh]

"DIHWIDT" means, "Doctor, it hurts when I do this", right? 😆

[cfa]

Is this an issue with exit or with threading and phaser order?

It seems like the latter might be worth documenting but I'm unsure how this relates to exit.

[lizmat]

No. It was done with the conscious decision that the first time exit is called, it fixates the exit value.

END blocks are guaranteed to always work on a normal exit, any other phasers might not as exit bypasses the whole call chain.

Note that this is different from throwing an exception: that won't actually exit until all applicable phasers have run.