tool_root_lock.h File Reference

The lock that guards the working directory one ServerManager's in-process and plugin servers resolve against (gh#158, gh#160). More...

#include <entropic/entropic_export.h>
#include <atomic>
#include <shared_mutex>
#include <string>
#include <thread>

Include dependency graph for tool_root_lock.h:

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Classes
class	entropic::ToolRootLock
	Shared/exclusive lock whose exclusive side is re-entrant for its owner, and whose owner passes through the shared side. More...
class	entropic::ToolRootShared
	RAII shared hold on a ToolRootLock (owner pass-through aware). More...

Namespaces
namespace	entropic
	Activate model on GPU (WARM → ACTIVE).

Detailed Description

The lock that guards the working directory one ServerManager's in-process and plugin servers resolve against (gh#158, gh#160).

Why this exists

FilesystemServer, BashServer and GitServer hold ONE working directory each, and a sandboxed delegation (gh#160) re-points all of them at its sandbox for the child's whole run. With concurrent_sessions on (the v2.13.0 default) a second, unbound session dispatches on the SAME default server set at the same moment, so without this lock its read_file("notes.md") resolved inside the OTHER session's sandbox — and the swap itself was an unsynchronized write of a std::filesystem:: path (and an ignore-rule reload) racing that read.

Contract

• EXCLUSIVE: taken by a thread that re-roots the servers, and held from sandbox entry to restore. Re-entrant for the owning thread, because a nested delegation re-enters on the same thread.
• SHARED: taken around every in-process / plugin tool dispatch. The exclusive owner passes straight through — its own child's calls are exactly the ones that SHOULD see the sandbox.

So another session's dispatch WAITS while a sandbox is in place, and then resolves against its own root. The parallel alternative is a workspace per session (gh#166), which has its own server set and its own lock.

Lock order

Outermost of the generation-path locks: ToolRootLock (exclusive, held across a child's run) → generation_mutex_ → swap_mutex_ / records_mutex_ → transition_mutex_ / mtp_mutex_. The SHARED side is taken only at tool dispatch, where a run thread holds none of those, and nothing inside a dispatch takes a generate entry point — so no holder of an inner lock ever waits on this one.

Version

2.13.0

Definition in file tool_root_lock.h.