add async interfaces

[cs01]

Add async alternatives to all sync methods. This will make pygdbmi more efficient because it will be event-based, not polling based.

[barollet]

Hi, I needed this async feature on my project so I went for a thread based implementation.

I can PR you the code if you want because indeed pygdbmi is much much faster.

However as I only needed async primitives (I can provide sync interface at a higher level in my project) I changed the interface and I would like to quickly discuss the interface so I can make a clean PR.

The interface is currently:

• sync write and wait for timeout
• sync read and wait for timeout My interface is:
• async write
• async non-blocking read
• async blocking read until the next GDB output At a higher level I have a synchronous write that writes a command to GDB and returns when the command is finished with all GDB output. I can also put this synchronous code in the PR.

My problem is that my implementation is thread based and I'm not sure how it can be compatible with code already written by the community. The IOManager spaws a read thread and a write thread. The write thread is in an infinite loop and reads command from a queue and writes them to GDB stdio. The read thread is also in an infinite loop and reads from GDB stdout and puts it into another queue (I don't read stderr but if this is needed it shouldn't be hard). When we exit the controller, the IOManager closes the two threads and exits so the controller can be terminated.

There is no timeout anywhere in my implementation so I think synchronous code already written with timeouts wont work with this. I don't know what is the best solution, do I create a GDBAsyncController that uses this thread based implementation or do I rewrite the current synchronous primitives by just waiting for the timeout and returning the result of the async calls ?

[matkuki]

Hey @barollet Could you post the code with the threaded async functionality? It sounds awesome! I'm experiencing missing responses when timeouts are too small, would your implementation fix this?

Thanks

[barollet]

Hi, I think it fixes your problem. You read response dicts one by one with no timeout with a blocking read or a non-blocking read so you can stop reading when you have a end of command or something. I have this kind of code in my project: write a command then read the result until the end of the result is received.

I don't have answers from the pygdbmi developers so maybe I will open a pull request with the code so you can access it and they can tell me what I need to change for the change to be accepted. I will put my version without extra work so there are some breaking changes but I can answer questions if something is not clear, I'll put the code today or tomorrow.

[barollet]

@matkuki I added a pull request. I just put my local code in the fork before sending the pull request. So maybe the easiest way to use it is to clone my fork and copy paste the folder with the library source on your local project. That is how I do before I have an answer from the developers so I can do a proper pull request and the code could be merged. So maybe you should expect breaking changes if the feature is merged one day.

I really only tested it on my machine for my project so if you have some issue maybe you can contact me by email to be sure to have a quick answer.

[matkuki]

@barollet Excellent, thank you 👍👍👍