Add ability to wait (with timeout) for the (gdb) "prompt".

[PlasmaHH]

Is your feature request related to a problem? Please describe.
I am looking into enhancing one of my project that is using a self written way to talk to gdb/mi and in that project I read some data with single commands and the result comes in chunks over tens of seconds. In my code I normally wait for the (gdb) string, which indicates that gdb is done writing the data, however trying pygdbmi the read functionality (_get_responses_unix) seems to entirely be based on timeouts.

Describe the solution you'd like
Add an option ( or make it the default ) to wait for the (gdb) prompt to indicate a commands output completion. Ideally one would have two timeouts: one for the whole read operation of all output, and one for the time after the last data is read.

Describe alternatives you've considered
Getting the data myself and just using pygdbmi as a parser, but thats probably not as neat.

Additional context
Add any other context or screenshots about the feature request here.

[lesnake]

Hello,
I think this is a must have.

I've spent quite some time figuring, on MS Windows, why the begining of the responses was randomly missing.

The problem is fixed by checking the that the end of the response is what you, @PlasmaHH, expect : "(gdb) \n", as defined in the MI protocol.

(btw, I dont understand the link between my problem and the solution)

Browsing the code, I found various attempts to detect the end of the transmission, capture what arrived after the timeout (If I understood properly) but none was including the protocol specification, which may make life easier. There is also a tradeoff between timeouts and reactivity. The timeout seem to be the only exit condition.

Here is what fixed my problem:

def _get_responses_windows(self, timeout_sec: float) -> List[Dict]:
[snip]
# Added initialization
raw_output = b''
while True:
[snip]
 elif time.time() > timeout_time_sec:
                break
[snip]
# Added detection of end of response mark
elif b"(gdb) \n" in raw_output:
                break

This code is also much faster, because it does not use timeout to leave the loop.

There are multiple pull requests, but reading them do not attempt to use the protocol.

Let me know if this is what you have on the back of your head.

PM