G9SP Response Queue IndexError Fix

[mslaffin]

Context from PR#53:

I believe this was effectively the error that was happening:

>>> import queue
>>>
>>> q = queue.Queue()
>>> item = q.queue[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: deque index out of range
>>>

[bwalkerMIR]

This error has showed up a lot!!

[AryanSV5]

Tested branch in lab on 2/10/2025-11:39am and the index error no longer comes up. Neither the console or logs displays the error. Ran tests with SIC individually and all also with other subsystems.

[mark11778]

It showed up again, but after ^ those commits, no longer being output to log ... but on disconnection (of the G9) the program stops responding

[mslaffin]

hey @mark11778 looks like you caught another instance of a direct-access of .queue[0]. I have some ideas about what's happening.

Your first change e37df8c changed to get_nowait()

- return self._response_queue.queue[0]
+ return self._response_queue.get_nowait()

this seems problematic because get_nowait actually removes the item from the queue, so each time we check the status, this actually consumes/removes the data instad of just reading the latest status.

Then it looks like you reverted back to looking at .queue[0] but with an empty check first. I think this sort of reintroduced the original thread-safety problem. The fact that the program hangs on disconnect is probably due to the GUI thread blocking because we're still trying to access the queue unsafely..

I'll push some changes to get_interlock_status that aligns this with the pattern Aryan tested in _communication_thread

[mark11778]

Ope, I missed your comment from before, but I was actually talking to Brandon about the same thing. I too was saying that I think it is an issue with how we are handling the threading locks.

This might also problem that the DP16 also shares to some extent

I added some of the contents that was originally in the auto comport detection, which closes the com port on disconnection, but I wonder if that is problematic with the thread ... but anyways, I was able to get it to disconnect without crashing (all be it took 30s or so(was not counting)), but on reconnection it stop responding again

[mark11778]

After some of the changes on how the bytes are being read in, the indicators now, show disconnection basically instantly, for reconnection(with only the SIC running and connected) it takes 6-7s.

But, no longer throwing index errors or crashing the GUI

Edit: tested it again with all subsystems excluding power supplies, got the same results

[mark11778]

Should be ready to merge into develop now