Skip to main content

Module table

Module table 

Source
Expand description

The live sessions, and how a container is matched against them. Concept 8: a container that already has a live session is not opened twice, because two sessions on one container would both repack it and the second write-back would overwrite the first with nothing said.

§Neither key is enough on its own

§8 says to key on file identity rather than on a path, and gives the reason: a container reachable under two hard links is two paths and one file, and a canonical path cannot see that.

What §8 does not account for — found while writing identity.rs — is that write-back replaces the container by renaming a new file over it, so a container acquires a new inode every time a session saves. An identity recorded when the session opened stops matching the file at that path after the first write-back, and the next invocation of the same container would find no entry and open the second session that all of this exists to prevent.

So a lookup matches on either. The path is stable across replacement and blind to hard links; the identity is the opposite. Together they cover both, and the case where they disagree is handled correctly rather than by accident: after a write-back through one of two hard links, §7 says the other name still points at the original with the old contents, so the two really are different files by then — different path, different identity, no match, and a new session, which is right.

Structs§

Table
The sessions this instance is holding.