Investigate why the RE panic test hangs pytest on exit

[tacaswell]

bluesky/src/bluesky/tests/test_run_engine.py

Lines 776 to 820 in 5df94da

	def test_sigint_many_hits_panic(RE):
	raise pytest.skip("hangs tests on exit")
	pid = os.getpid()
	def sim_kill(n):
	for j in range(n):
	print("KILL", j, ttime.monotonic() - start_time)
	ttime.sleep(0.05)
	os.kill(pid, signal.SIGINT)
	def hanging_plan():
	"a plan that blocks the RunEngine's normal Ctrl+C handing with a sleep"
	yield Msg("null")
	ttime.sleep(5)
	yield Msg("null")
	start_time = ttime.monotonic()
	timer = threading.Timer(0.2, sim_kill, (11,))
	timer.start()
	with pytest.raises(RunEngineInterrupted):
	RE(hanging_plan())
	# Check that hammering SIGINT escaped from that 5-second sleep.
	assert (ttime.monotonic() - start_time) < 2.5
	# The KeyboardInterrupt but because we could not shut down, panic!
	assert RE.state == "panicked"
	timer.join()
	with pytest.raises(RuntimeError):
	RE([])
	with pytest.raises(RuntimeError):
	RE.stop()
	with pytest.raises(RuntimeError):
	RE.halt()
	with pytest.raises(RuntimeError):
	RE.abort()
	with pytest.raises(RuntimeError):
	RE.resume()
	with pytest.raises(RuntimeError):
	RE.request_pause()

If not skipped this test hangs the pytest process on exit until the CI runners kill it (or you kill it with ctrl-c manually locally).

I suspect that this is because in the panicked state we have lost control of the RE + RE thread (which is why we panicked so maybe this is OK). If we are lucky, the fix is in the fixture cleanup, if we are unlucky the we need to try harder to save a panicked RE.