mirror of
https://github.com/HeyPuter/gex.git
synced 2026-11-13 20:12:43 -10:00
velzieandClaude Opus 5.5
b52c2f6baf
Process A numbers many blocks, then runs libfoo; B runs libfoo first (the unit cache hands it A's Modules, whose gex.dense names A's base), then its own code; B forks and the child calls both. Results must match a native run, and GEX_DENSE_DEBUG must log adopts of a Module carrying another base (about 460 per run, eager or deferred adopt). With 5d0fd874's fix reverted the results still match: adopt numbered the slots and the blocks at the same foreign base (consistent in the child), and the child instantiates none of those Modules -- it misses and the unit cache serves the units again. So the old behaviour was a latent hazard, not an observed wrong result; only the log check fails without the fix. run-node passes GEX_ADOPT_AFTER through; the GEX_DENSE_DEBUG install line names the pid and notes a precompiled Module from another base. Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_781bad2ec05143db9067c86b4b2678e2
16 lines
299 B
C
16 lines
299 B
C
/* The library both processes load: the unit cache hands the second one the
|
|
* Module the first compiled. */
|
|
int foo_f(int x)
|
|
{
|
|
int s = 0;
|
|
for (int i = 0; i < x; i++) s += (i % 7) * 3;
|
|
return s + 1;
|
|
}
|
|
|
|
int foo_g(int x)
|
|
{
|
|
int s = 1;
|
|
for (int i = 0; i < x; i++) s = s * 5 + (i & 3);
|
|
return s;
|
|
}
|