No description
Find a file
Folling 1990c950d9
fixup IKA_API os detection
Signed-off-by: Folling <mail@folling.io>
2025-04-15 12:08:11 +02:00
docs finalize schema/data setup 2025-04-15 12:08:10 +02:00
include fixup IKA_API os detection 2025-04-15 12:08:11 +02:00
src check result from 'ikarus_default_value' SQLite function creation 2025-04-15 12:08:11 +02:00
tests finalize schema/data setup 2025-04-15 12:08:10 +02:00
tools/cmake/toolchains finalize schema/data setup 2025-04-15 12:08:10 +02:00
vendor update cppbase 2025-04-15 12:08:11 +02:00
.clang-format update dependencies 2025-04-15 12:08:10 +02:00
.clang-tidy add src/ikarus subdir and make names unique for objects per scope 2025-04-15 12:08:06 +02:00
.gitignore a new beginning 2025-04-15 12:07:55 +02:00
.gitmodules update vendor libraries 2025-04-15 12:08:10 +02:00
CMakeLists.txt rename to libikarus and remove default cmake prefix 2025-04-15 12:08:10 +02:00
CMakePresets.json finalize schema/data setup 2025-04-15 12:08:10 +02:00
LICENSE.md finalize schema/data setup 2025-04-15 12:08:10 +02:00
README.md change error system & function signatures 2025-04-15 12:08:04 +02:00

Data Longevity

All data returned by libikarus is ephemeral and only represents the state of the project at the time of the request. A snapshot if you will. One must not rely on it representing the actual state of the project at any given time. The data is simply copied from the underlying data sources and returned to the caller.

No mechanisms are provided to avoid race conditions. libikarus itself should only be used in a single-threaded context. However, nothing breaks if you do use it in a multithreaded context, that is, libikarus is threadsafe. You just cannot rely on the data being consistent. This goes especially for inter-process access to the same project.