4 Commits

Include renames

Author	SHA1	Message	Date
dtourolle	87c5f98d04	fix: start and stop in the topological order that was computed ... make_network computes Topo for the cycle check and then discarded it. The node vector was filled in edge-declaration order — and then named user_nodes_topo_ and relied upon as if it were sorted. halt() stops in its reverse, and shutdown() walks it forwards stopping each node and draining its outputs before the next, which is a graceful drain only if the order really is sources-first. It held for every network in this tree because edges happen to be declared in pipeline order, so the two coincided. Declared any other way — which is legal and which make_network otherwise accepts in silence — shutdown stops a consumer before its producer and discards whatever was queued in front of it. The order now comes from Topo::topo, which is already sources-first. Fanout nodes appear there too and are skipped, since they are owned separately in fanout_storage; they are still started after the user nodes and stopped before them, so a fanout sitting between two user nodes is not staged precisely during a drain. That is a smaller gap than the one being closed and is left alone rather than restructured on the way past. The test declares the sink edge first and the source edge last, and asserts through shutdown() rather than by reading the order back — the order is private, and what it buys is the point. A sources-first shutdown lets the backlog queued in front of the slow relay reach the sink; stopping the relay first discards all of it. Worth recording how this went, because it is the more useful half: the new test segfaulted, 12 runs in 20. Not a fault in the ordering change — it was stopping sources first that finally put a live consumer behind a dead producer, which is the condition the previous commit's crash needs. The ordering fix did not introduce that bug, it made it reachable. Verified in both directions: with declaration order the sink receives nothing after shutdown begins; with topological order it receives the whole backlog.	2026-08-05 15:14:35 +02:00
dtourolle	0f277c0f98	fix: the drain loops must terminate, and must drain the right channels ... shutdown()'s drain step was an unbounded while (anything, anywhere, is non-empty) poll every channel Three defects in one loop. It drained the wrong thing. Stopping a node should wait for that node's own outputs before moving to the next layer; this waited for the entire graph to fall idle each time. The dynamic Network's version made it explicit — it took a node name and ignored it. Both now track which node feeds each probe and wait only on those. It had no deadline, so anything wedged downstream turned a graceful shutdown into the hang it exists to avoid. Now bounded two ways, because a stalled consumer and a slow one fail differently: a deadline for fill that never changes, and a no-progress counter that keeps waiting as long as the queue is shrinking, so a slow drain is not cut short merely for taking a while. And it could fail to terminate with nothing wedged at all. current_fill came from a snapshot that loaded tail_ before head_. A concurrent pop between the two reads yields a head_ past the sampled tail_, and the unsigned difference wraps to ~2^64 — so a poll for "is it empty yet" runs forever on a channel that is in fact empty. Both indices only ever increase, so loading head_ first can at worst under-report a concurrent push, which this loop tolerates and a wrap does not. size() and snapshot() are both corrected; size() feeds approx_size(), which is what node readiness checks call. Giving up is now reported rather than silent, because undrained data at that point is about to be discarded by the stop that follows, and a graceful shutdown quietly dropping values is the thing worth knowing about. Verified in both directions: with the old loop the new case is killed at a 30 s timeout; with this it returns in under a second, having reported four items its wedged consumer never took. Full suite 138/138. Note the drain timeout is per node and defaults to 5 s, so a graph of N stalled nodes can still take N x 5 s to shut down. That is a deliberate trade against cutting off legitimate slow drains, and set_drain_timeout() exists for callers who want it tighter.	2026-08-05 14:25:00 +02:00
dtourolle	9ce581b5ce	Fixed bug when generating identical fanouts	2026-05-09 08:36:51 +02:00
dtourolle	2bca2a7554	Add static network	2026-05-08 20:00:15 +02:00