docs(fspy): document shared-memory facade ownership semantics#521
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
wan9chi
force-pushed
the
fspy-shm-lifecycle
branch
from
7121ef2 to
e1d4fa0
Compare
wan9chi
force-pushed
the
fspy-shm-facade
branch
2 times, most recently
from
3d5e984 to
9ca03e0
Compare
wan9chi
force-pushed
the
fspy-shm-lifecycle
branch
from
e1d4fa0 to
1e4ee5f
Compare
wan9chi
force-pushed
the
fspy-shm-lifecycle
branch
from
1e4ee5f to
67ee808
Compare
wan9chi
force-pushed
the
fspy-shm-lifecycle
branch
from
67ee808 to
669ab52
Compare
wan9chi
force-pushed
the
graphite-base/521
branch
from
4f7087d to
cb580c2
Compare
wan9chi
force-pushed
the
fspy-shm-lifecycle
branch
from
669ab52 to
70822fb
Compare
wan9chi
force-pushed
the
fspy-shm-lifecycle
branch
from
70822fb to
8716c77
Compare
Document the cross-platform create/open contract of the fspy_shm facade: owner lifetime gates new opens, already-open views survive owner teardown, and Windows may keep the name resolvable while other handles hold the section object alive. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
wan9chi
force-pushed
the
fspy-shm-lifecycle
branch
from
8716c77 to
4e0e749
Compare
wan9chi
changed the title
Co-authored-by: GPT-5 Codex <codex@openai.com>
Co-authored-by: GPT-5 Codex <codex@openai.com>
Co-authored-by: GPT-5 Codex <codex@openai.com>
Co-authored-by: GPT-5 Codex <codex@openai.com>
Co-authored-by: GPT-5 Codex <codex@openai.com>
Co-authored-by: GPT-5 Codex <codex@openai.com>
Co-authored-by: GPT-5 Codex <codex@openai.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2b0d301fbe
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| lock_file.try_lock_shared()?; | ||
|
|
||
| let shm = fspy_shm::open(&self.shm_id, self.shm_size)?; | ||
| let shm = fspy_shm::open(&self.shm_id)?; |
There was a problem hiding this comment.
On Windows, opening without the original capacity lets shared_memory recompute the opened view length from the OS mapping, which is page-rounded, while the receiver's owner still reports the requested channel(capacity) length. For non-page-aligned capacities, a sender can therefore use a larger shm.len() for ShmWriter bounds checks and advance the shared header past the receiver's slice, so ReceiverLockGuard::iter_frames can panic when it slices content[..content_size] after enough writes. Keep the configured size in ChannelConf or clamp opened views to the requested capacity.
Useful? React with 👍 / 👎.
1 participant
Motivation
Define how shared-memory owners and opened views behave before replacing the platform backends.
Changes
create,open, owner drop, and opened-view lifetime.opento take only the identifier and derive the mapped size from the operating-system object.ChannelConf.