fix: open() after a legacy start() left two producers feeding the queue (review of #4)

[thorwhalen]

Post-merge refute review of #4.

#4's main change holds: every open() gets its own worker, and is_alive()/join() follow it. The gap is the legacy path it explicitly supports ("a reader started the legacy way, with start() ... falls back to Thread's own"):

reader.start()   # runs in self; _worker stays None
reader.close()   # sets the stop flag; self may still be sleeping
reader.open()    # _stop_previous_worker: _worker is None -> nothing to stop
                 # then clears the stop flag -> the legacy run never sees close()

The result is two producers appending to the same queue with interleaved indices, which _stop_previous_worker's docstring says must not happen. Before #4, this sequence raised RuntimeError: threads can only be started once. Now it degrades silently.

Fix. When there is no _worker but self is running (Thread.is_alive(self)), _stop_previous_worker treats self as the previous worker: it signals it, waits up to reopen_timeout_s, and raises if it does not stop.

Tests.

• test_open_after_a_legacy_start_leaves_a_single_producer: fails on master, passes here.
• test_stop_does_not_shadow_thread_internals asserted callable(reader._stop), but Thread._stop was removed in Python 3.13, so that test fails there regardless of the code. It now asserts that no Event shadows the name, which is the property the test protects.

All 7 tests pass locally on py3.10 and py3.13.

Self-reviewed only (the dispatching run disallowed sub-agents).

🤖 Generated with Claude Code

https://claude.ai/code/session_011HSBVhDjRU4apSLcRkavv9