582503c interrupts a streaming request's job when its client disconnects. For .bus sub and plain generated streams, the thread is released right away. For handlers that use .cat --follow or .last --follow, the thread stays parked until the next frame matching the follower's topics arrives, because cross-stream's follow loop doesn't check the interrupt. Details and repro are in cablehead/xs#164.
On c7383e2 (cross-stream 0.14.0), 20 disconnected SSE clients on a .cat --follow -T "a,b,c" handler left one thread each parked (38 threads against a baseline of 18) until a single matching frame was appended. Then it dropped straight back to 18.
When xs#164 ships
Re-test when cablehead/xs#164 is released
582503cinterrupts a streaming request's job when its client disconnects. For.bus suband plain generated streams, the thread is released right away. For handlers that use.cat --followor.last --follow, the thread stays parked until the next frame matching the follower's topics arrives, because cross-stream's follow loop doesn't check the interrupt. Details and repro are in cablehead/xs#164.On
c7383e2(cross-stream 0.14.0), 20 disconnected SSE clients on a.cat --follow -T "a,b,c"handler left one thread each parked (38 threads against a baseline of 18) until a single matching frame was appended. Then it dropped straight back to 18.When xs#164 ships
cross-streaminCargo.tomlto the release with the fix.cat --followhandler, disconnect them, and with no new frames appended, confirm the thread count returns to baseline within about a second.last --followtest_handler.rsdisconnect test (the ten-subscriber case added in582503c) to cover.cat --follow, so this stays fixed