1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
//! Thread-local re-entrancy guard for the provider-fanout phase of commit.
//!
//! Re-entrant writes from inside an `IndexProvider::on_change` callback are
//! misuse: a nested write would deadlock or recurse indefinitely. We detect the
//! same-thread case here via a thread-local counter and let `begin_write` panic
//! with a clear message; the `notify_providers` boundary catches that unwind so
//! the commit still completes.
//!
//! ## v1.2 relocation — fanout now runs on the committer thread
//!
//! Before v1.2 fanout ran on the writer (session) thread under the held write
//! lock. Since v1.2 (BRIEF 1) the snapshot publish + provider fan-out run on the
//! single per-graph **committer thread** (`committer.rs`); `WriteTxn::seal`
//! releases the write lock on the session thread before handing the bundle off.
//! This guard is therefore set on the committer thread during fan-out. It stays
//! sound precisely because there is exactly **one** committer: a provider whose
//! `on_change` re-enters `begin_write` does so on the committer thread, where
//! `in_fanout()` is true, so it panics before locking. (The committer itself
//! never holds the write lock — even compaction builds its dense graph on the
//! caller thread and hands the committer a pre-built snapshot — so the panic is
//! about preventing an unbounded re-entrant publish, not a self-deadlock on the
//! write lock.) A second committer would break this thread-local reasoning —
//! the single-committer constraint is load-bearing (v1.2 design §4, §7.7).
//!
//! ## Cross-thread misuse — out of scope
//!
//! A provider whose `on_change` spawns a worker thread, calls `begin_write()`
//! on that worker, AND blocks waiting for the worker (e.g., `JoinHandle::join`,
//! `mpsc::Receiver::recv`) will deadlock. The worker blocks on the held write
//! lock; the outer `on_change` blocks waiting for the worker; the outer commit
//! cannot release the lock until `on_change` returns. This is a circular
//! wait the engine cannot detect without tracing causal thread ancestry.
//!
//! v1.0 contract: `IndexProvider::on_change` MUST NOT initiate a write
//! transaction, directly or indirectly via a spawned thread it then waits on.
//! Cross-thread reentry is documented misuse, not a detectable footgun.
//! Catching the same-thread case here is a courtesy that flags the obvious
//! mistake; cross-thread waits are the provider author's responsibility.
use Cell;
thread_local!
/// Returns true if this thread is currently inside an
/// [`IndexProvider`](crate::IndexProvider) callback fanout.
pub
/// RAII guard that increments `FANOUT_DEPTH` for the duration of provider
/// fanout. Drop semantics make the decrement panic-safe so that a panicking
/// provider cannot leave the counter wedged above zero.
pub