Perhaps we can jerry rig an atomic compare and set on the type id? Then we'll just need an otherwise unused type to signal that someone else is already in the process of calculating.

Wouldn't that only work for mixed unions?

I suppose we could force a mixed union using an appropriate type to signal work in progress?
The value of the class variable would effectively be typeof({{ yield }}) | WorkInProgress | Nil.
If the type of the block is a reference type, WorkInProgress could be a struct type and vice versa. That would mean two different signal types and select the appropriate one.

This is related to #15085. Perhaps we could use the same mechanism for both (for example a spin-lock on the type id).

This issue has been mentioned on Crystal Forum. There might be relevant details there:

https://forum.crystal-lang.org/t/charting-the-route-to-multi-threading-support/7320/1

The simplest solution would be to replace the "lazy method" with an explicit assignment: thread safety would handled by __crystal_once and it would even check for recursion (win-win situation). Since {{yield}} is injected as begin; ...; end it works perfectly...

With the exception that @@cvar = value is considered user code, and will be inlined right into __crystal_main and be eagerly loaded when the program starts. Damn, that broke the lazyness.

Note: apparently codegen will always declare & initialize all class vars with an initializer (default value); while LLVM will optimize them away if the program never accesses them, dev builds (i.e. -O0) will always initialize all class vars (be they accessed or not).

I tried to reused __crystal_once but it didn't go well: the Mutex for example is only used when preview_mt is enabled (fixable) but the fun only takes a proc pointer with a closure pointer, and that won't work, and I get invalid memory accesses with the example above.

I'll have to write something custom, that will take and call an actual Proc and will need a Mutex.

I was eventually able to reuse Crystal.once by adding a yielding version.

Using the captured block would allow for a better optimization: always inline the quick check and never inline the actual initialization.

But capturing the block would be breaking change (can't return nor break anymore) even though the cases in std lib/spec where we used return didn't work as expected: the value was returned but the class var was never set.

We might want to introduce an opt-in flag.

Capturing the block would be nice 👍
The breaking change is intricate though. If any initializer code uses return or break, it probably does so without realizing or intending the implication (we even have a few cases in stdlib).
So one might even argue that changing to a captured block might help discover bugs in lazy initializers 🤷 It can be a good thing to let that code break that behaves unexpectedly/unintendedly.