Add fiber safety to `__crystal_once` & `class_[getter|property]?(&)` macros #15340

ysbaddaden · 2025-01-13T17:14:43Z

Fixes a couple issues:

__crystal_once isn't fiber safe (concurrency issues); the initializer can be invoked multiple times from multiple fibers (despite using Mutex).

This issue is fixed by always using the Mutex not only when MT is enabled.
class_getter, class_getter?, class_property and class_property? are neither thread nor fiber safe (parallelism & concurrency issues).

This issue is fixed by reusing Crystal.once.

NOTE: calls to the aforementioned macros had to be dropped in Fiber and Thread because Mutex depends on them and we need the later to implement said macros (chicken/egg => infinite recursion => stack overflows).

This is a breaking change because the block is now captured, and we can't return from it anymore. This is outlined by the commit that fixes SocketSpecHelper.supports_ipv6? that didn't work as expected anyway (the @@supports_ipv6 class var was never set to true). The block is no longer captured. We might want to introduce a compile time flag to enable the new behavior as it could help with some LLVM inlining behavior (inline the check).

builds on top of #15333
closes #14905

ysbaddaden · 2025-01-13T17:15:32Z

By duplicating the Crystal.once logic we might be able to avoid the breaking change (we let Crystal inline the blocks instead of passing a proc pointer, which avoids to capture the block). We won't be able to take advantage of the AlwaysInline + NoInline annotations optimization... but that may be acceptable.

ysbaddaden · 2025-01-13T17:28:53Z

Wonderful. CI decided to blow up 😮‍💨

~~It might have something to do with musl-libc.~~ It was an issue with musl (another thread classvar). Windows and GNU seem fine. But mingw and openbsd were broken (yet another thread class var). They're now explicitly initialized by Thread.init before we need them.

MacOS is broken ~~for some other reason~~ because CI still uses LLVM 11 😨 and there's an issue with LLVM 14 and below apparently (which may explain why it breaks on some older crystal releases). ~~I can't reproduce when cross compiling to x86_64-apple-darwin on a Linux host and LLVM 18.1.8. It correctly compiles a .o file.~~ This should be fixed: the compiler was missing a pointer cast.

~~The interpreter is broken because of flag.value = :processing. It's confused by the assignment through a pointer and can't translate the symbol to the enum value:~~

Error: BUG: missing upcast_distinct from Symbol to Crystal::OnceState (Crystal::SymbolType to Crystal::EnumType)

That was easy to fix, but now it segfaults on the IO.pipe { } interpreter spec for no immediate reason: I don't see where it would use a global and debugging the interpreter is an impossible task. It might be something to do with const or classvars used by the interpreter itself 🤔 The interpreter actually never calls __crystal_once_init and doesn't use crystal once at all.

@BlobCodes

Co-authored-by: David Keller <[email protected]> Based on the PR by @BlobCodes: crystal-lang#15216 The performance improvement is two-fold: 1. the usage of a i8 instead of an i1 boolean to have 3 states instead of 2, which permits to quickly detect recursive calls without an array; 2. inline tricks to optimize the fast and slow paths. Unlike the PR: 1. Doesn't use atomics: it already uses a mutex that guarantees acquire release memory ordering semantics, and __crystal_once_init is only ever called in the main thread before any other thread is started. 2. Removes the need for a state maintained by the compiler, yet keeps forward and backward compatibility (both signatures are supported).

@BlobCodes

Co-authored-by: David Keller <[email protected]> @BlobCodes: I noticed that adding this code prevents LLVM from re-running the once mechanism multiple times for the same variable. Modified to avoid an undefined behavior when the assumption doesn't hold that doubles as a safety net (print error + exit).

@BlobCodes

Co-authored-by: David Keller <[email protected]> @BlobCodes: I think it would be better to print the bug message in `Crystal.once` instead of `__crystal_once` to reduce complexity at the callsite. The previous unreachable method can then be used in the inlined `__crystal_once` so LLVM also knows it doesn't have to re-run the method. It's now even safe because `Crystal.once` would panic if it failed; it should already be impossible, but let's err on the safe side.

We need a Mutex to protect against recursion and to make sure the lazy initializers only run once, but Mutex depends on the current fiber, and indirectly the current thread, which themselves may not have been initialized yet and will lead to an infinite recursion once we protect the class getter and property helpers.

Reuses the logic for `__crystal_once`.

Protects against recursion and adds thread (parallelism) and fiber (concurrency) safety to class var initialization.

The initializer block is now captured, and we can't return from a captured block. This outlines that the previous commit is a BREAKING CHANGE! The `class_getter?` version used skip over the intent to cache the result in `@@supports_ipv6` (it returned from the generated function, not from the block), so whenever IPv6 was supported every test was creating yet-another TCPServer (oops).

1. it fails to translate symbol to the enum value 2. it doesn't call `__crystal_once_init`

Avoids a breaking change at the expense of some optimization.

ysbaddaden added kind:refactor breaking-change topic:stdlib:runtime labels Jan 13, 2025

ysbaddaden self-assigned this Jan 13, 2025

ysbaddaden added 7 commits January 14, 2025 09:53

Fix: macro 'class_property' must be defined

6ebfcf4

Fix: only enabled for 1.16.0-dev (not 1.15.0-dev)

71a1c4d

Add LLVM optimization to legacy __crystal_once

2296069

Fix: LLVM 14 and below need explicit pointer cast (i8* -> i1*)

2c1c20b

ysbaddaden force-pushed the fix/add-fiber-safety-to-crystal-once branch from d2a3376 to f4347db Compare January 14, 2025 11:58

ysbaddaden added 9 commits January 14, 2025 18:58

Fix: missing :nodoc:

273978b

Fix: initializing constants and class vars is concurrency unsafe

0460ba0

Add Crystal.once to protect classvar lazy initialization

211ac7b

Reuses the logic for `__crystal_once`.

Use Crystal.once in lazy initializers

bbeda3d

Protects against recursion and adds thread (parallelism) and fiber (concurrency) safety to class var initialization.

crystal tool format

62ad630

Fix: interpreter issues

e2629a2

1. it fails to translate symbol to the enum value 2. it doesn't call `__crystal_once_init`

Fix: don't capture block in Crystal.once(flag, &)

d4fb901

Avoids a breaking change at the expense of some optimization.

ysbaddaden force-pushed the fix/add-fiber-safety-to-crystal-once branch from f4347db to d4fb901 Compare January 14, 2025 18:29

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add fiber safety to `__crystal_once` & `class_[getter|property]?(&)` macros #15340

Add fiber safety to `__crystal_once` & `class_[getter|property]?(&)` macros #15340

ysbaddaden commented Jan 13, 2025 •

edited

Loading

ysbaddaden commented Jan 13, 2025 •

edited

Loading

ysbaddaden commented Jan 13, 2025 •

edited

Loading

Add fiber safety to __crystal_once & class_[getter|property]?(&) macros #15340

Are you sure you want to change the base?

Add fiber safety to __crystal_once & class_[getter|property]?(&) macros #15340

Conversation

ysbaddaden commented Jan 13, 2025 • edited Loading

ysbaddaden commented Jan 13, 2025 • edited Loading

ysbaddaden commented Jan 13, 2025 • edited Loading

Add fiber safety to `__crystal_once` & `class_[getter|property]?(&)` macros #15340

Add fiber safety to `__crystal_once` & `class_[getter|property]?(&)` macros #15340

ysbaddaden commented Jan 13, 2025 •

edited

Loading

ysbaddaden commented Jan 13, 2025 •

edited

Loading

ysbaddaden commented Jan 13, 2025 •

edited

Loading