andrew/libakstdlib
1
0
Fork 0
Code Issues 26 Pull Requests Actions Packages Projects Releases Wiki Activity

The pinned libakerror is 1.0.0 and has an unlocked error pool; 2.0.1 locks it #2

New Issue
Open
opened 2026-08-02 18:53:15 -04:00 by tachikoma · 1 comment
tachikoma commented 2026-08-02 18:53:15 -04:00
Collaborator
Copy Link

Source: TODO.md §1.1 (at 669b2b3), corrected against the tree while filing

The entry this came from is out of date, and the correction makes it
actionable. It said the error pool "is a fixed array handed out by
akerr_next_error() with no synchronisation of any kind", and that this is what
makes libakstdlib single-threaded, permanently blocked on a decision upstream.

That is true of the libakerror this repository pins, and false of libakerror
today:

Pinned here (deps/libakerror @ 5ff8790) Upstream
Version 1.0.0 2.0.1
akerr_mutex_lock in src/error.c 0 occurrences one recursive lock over both the pool and the status registry
src/lock.h absent present, with the reasoning for one recursive lock
Thread tests none tests/err_threads_pool.c, err_threads_handoff.c
docs/thread-safety.md absent present

libakgl and akbasic both pin 2.0.1 already. This repository is the one
left behind.

So the work is a submodule bump and what falls out of it, not a wait:

  • Bump deps/libakerror from 1.0.0 to 2.0.1. That is a major version — read
    libakerror's UPGRADING.md first, and note akerr_exit() is new and owns
    the status-to-exit-code mapping, which changed how a status above 255 exits.
  • Re-test the claim rather than assuming it: a concurrent smoke test here that
    fails against 1.0.0 and passes against 2.0.1.
  • Add a TSan job to .gitea/workflows/ci.yaml. libakerror runs one through
    scripts/thread_test.sh; this library runs none.
  • Then, and only then, take the "not thread-safe" warning out of README.md.

What may still be true after the bump. The pool is locked; that does not make
every wrapper here thread-safe, and the remaining IGNORE() leak (#3) is
unaffected by locking. Establish what is actually safe by testing it, and write
down what is not, rather than replacing one unverified claim with another.

Filed by Tachikoma (Claude Code, Opus 5, 1M context)

**Source:** TODO.md §1.1 (at 669b2b3), corrected against the tree while filing **The entry this came from is out of date, and the correction makes it actionable.** It said the error pool "is a fixed array handed out by `akerr_next_error()` with no synchronisation of any kind", and that this is what makes libakstdlib single-threaded, permanently blocked on a decision upstream. That is true of **the libakerror this repository pins**, and false of libakerror today: | | Pinned here (`deps/libakerror` @ 5ff8790) | Upstream | |---|---|---| | Version | **1.0.0** | **2.0.1** | | `akerr_mutex_lock` in `src/error.c` | 0 occurrences | one recursive lock over both the pool and the status registry | | `src/lock.h` | absent | present, with the reasoning for one recursive lock | | Thread tests | none | `tests/err_threads_pool.c`, `err_threads_handoff.c` | | `docs/thread-safety.md` | absent | present | `libakgl` and `akbasic` both pin **2.0.1** already. This repository is the one left behind. **So the work is a submodule bump and what falls out of it**, not a wait: - [ ] Bump `deps/libakerror` from 1.0.0 to 2.0.1. That is a major version — read libakerror's `UPGRADING.md` first, and note `akerr_exit()` is new and owns the status-to-exit-code mapping, which changed how a status above 255 exits. - [ ] Re-test the claim rather than assuming it: a concurrent smoke test here that fails against 1.0.0 and passes against 2.0.1. - [ ] Add a TSan job to `.gitea/workflows/ci.yaml`. libakerror runs one through `scripts/thread_test.sh`; this library runs none. - [ ] Then, and only then, take the "not thread-safe" warning out of `README.md`. **What may still be true after the bump.** The pool is locked; that does not make every wrapper here thread-safe, and the remaining `IGNORE()` leak (#3) is unaffected by locking. Establish what is actually safe by testing it, and write down what is not, rather than replacing one unverified claim with another. --- Filed by Tachikoma (Claude Code, Opus 5, 1M context)
tachikoma added this to the 0.3.0 milestone 2026-08-02 18:53:15 -04:00
tachikoma added the defectdesign-decisionblast-radius:highstatus::grooming labels 2026-08-02 18:53:15 -04:00
tachikoma changed title from The error pool is a process-global array with no locking, and it is what makes this library single-threaded to The pinned libakerror is 1.0.0 and has an unlocked error pool; 2.0.1 locks it 2026-08-02 18:57:14 -04:00
tachikoma commented 2026-08-02 18:57:14 -04:00
Author
Collaborator
Copy Link

Reframed after checking the tree: the claim was true of the pinned libakerror 1.0.0 and false of upstream 2.0.1, which locks the pool. Retitled and rescoped to the submodule bump and the verification that has to go with it. libakgl and akbasic are both on 2.0.1 already.

Reframed after checking the tree: the claim was true of the pinned libakerror 1.0.0 and false of upstream 2.0.1, which locks the pool. Retitled and rescoped to the submodule bump and the verification that has to go with it. libakgl and akbasic are both on 2.0.1 already.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
abi-break
Cannot land without a soname bump
 api-gap
A caller cannot express something
 blast-radius:high
Ordering: highest blast radius
 blast-radius:low
Ordering: lowest blast radius
 blast-radius:medium
Ordering: middling blast radius
 defect
Wrong behaviour reachable from the public API
 design-decision
Needs a decision written down before code
 docs
Documentation, comments, AGENTS.md
 hygiene
Style, dead code, consistency
 packaging
Build, install, pkg-config, CMake config
 performance
Has a measurement behind it
 status::blocked
Waiting on something else -- a decision, a dependency, or another issue
 status::grooming
Not yet worked out: scope, approach or priority still being settled
 status::ready
Understood well enough to start: scope and approach are settled
 test-coverage
A gap in the suites, not a defect
No Label blast-radius:high defect design-decision status::grooming
Milestone
No items
No Milestone 0.3.0
Projects
Clear projects
No project
Assignees
Clear assignees
tachikoma andrew
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: andrew/libakstdlib#2
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?