Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add async interfaces #41

Open
cs01 opened this issue Feb 18, 2020 · 5 comments
Open

add async interfaces #41

cs01 opened this issue Feb 18, 2020 · 5 comments

Comments

@cs01
Copy link
Owner

cs01 commented Feb 18, 2020

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

@barollet
Copy link

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
Copy link
Contributor

matkuki commented Nov 11, 2022

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
Copy link

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
Copy link

@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
Copy link
Contributor

matkuki commented Nov 16, 2022

@barollet
Excellent, thank you 👍👍👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants