refactor(fspy-client): accept allocators from the interception layer - #685
Draft
wan9chi wants to merge 1 commit into
Draft
refactor(fspy-client): accept allocators from the interception layer#685wan9chi wants to merge 1 commit into
wan9chi wants to merge 1 commit into
Conversation
fspy benchmarklinuxmacoswindows |
wan9chi
force-pushed
the
agent/fspy-toplevel-allocators
branch
2 times, most recently
from
August 18, 2026 09:23
a7eb5cd to
9422045
Compare
wan9chi
force-pushed
the
agent/fspy-toplevel-allocators
branch
from
August 18, 2026 09:56
9422045 to
eccff03
Compare
wan9chi
force-pushed
the
agent/fspy-toplevel-allocators
branch
2 times, most recently
from
August 18, 2026 10:21
ba2af84 to
adc4e90
Compare
wan9chi
force-pushed
the
agent/fspy-toplevel-allocators
branch
from
August 18, 2026 15:33
adc4e90 to
38ed207
Compare
wan9chi
force-pushed
the
agent/fspy-toplevel-allocators
branch
from
August 18, 2026 15:58
38ed207 to
8127650
Compare
The pooled bumps that fspy_client_unix created internally for per-interception temporaries now come from the interception layer, so allocator choices live only at the top of the call stack: - try_handle_open, handle_exec, and RawExec::from_exec accept the allocator for their transient path and pointer-array storage. - The unix exec wrapper takes the allocator from each interception, so execveat shares its path-resolution bump with the exec-argument rebuild instead of drawing a second chunk from the pool. fspy_client_unix no longer creates any allocator, and its fspy_nostd_alloc dependency goes away with the last use. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
wan9chi
force-pushed
the
agent/fspy-toplevel-allocators
branch
from
August 18, 2026 16:09
8127650 to
65010b7
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
fspy_client_unix still created pooled bumps in the middle of call stacks for per-interception temporaries:
try_handle_opendrew one for path resolution, andRawExec's pointer-array build drew another during exec handling. Allocator choices belong at the top of the call stack, with everything below accepting a generic allocator — the layering the rest of the stack established.try_handle_open,handle_exec, andRawExec::from_execaccept the allocator for their transient path and pointer-array storage.execveat— which already owns a bump for its path resolution — shares that one bump with the exec-argument rebuild instead of drawing a second chunk from the pool.fspy_client_unix no longer creates any allocator.
🤖 Generated with Claude Code