Async traits

[SidongYang]

Hi, I'm using gdbstub crate very well. I'm writing code for gdbserver that controls embedded system in kernel. Preferred action is to write/read device file in implementing traits like SingleThreadSingleStep::step() or SwBreakpoint::add_sw_breakpoint(). I want to use async file write in these functions but they are not async callback. Is there any good way to call async function in these traits? or it needs some patch?

[daniel5151]

The short answer is that, unfortunately, gdbstub's current feature-level IDET traits are all sync, so unless you're willing to use block_on, there's no good way to call an async function from those handlers.

For context: the last time the question of async in gdbstub came up was in the context of the top-level GdbStub API and the Connection trait, which used to force users to block / periodically poll in order to handle certain aspects of the GDB RSP (see #36). That limitation was worked around in 0.6 with the introduction of the state-machine API, which tweaked the APIs to allow users to manually "pump" the GDB state machine with incoming data, thereby making it easier to integrate into whatever existing async infrastructure their project was using.

This solved the async transport question, but it didn't solve the async handler question, like you're running into.

It seems most folks don't really mind this limitation, but its certainly a limitation nonetheless. The async Rust ecosystem and language support has evolved a lot in the years since gdbstub began development, so it may be time to re-evaluate the possibility of leveraging async / await in gdbstub.

The questions that immediately come to mind here are:

• At the language level, how easy would it be to use async traits alongside gdbstub's IDET-based API?
• At the integration level, what would the binary size impact be of using async traits?
  • Would there need to be two parallel GdbStub core implementations, so non-async users don't pay the binary-size tax of having the library be based on async?
• At the gdbstub codebase level, what would be the best way to support both async and non-async families of traits?

I'm happy to use this issue as a tracking issue for folks to express interest in the feature, as well as explore / answer some of the questions I've posed above.

I'm not sure when I'll have cycles to do some of this work myself, but if you / other folks are interested in helping explore the design-space here, I could certainly try to find some more time and motivation to help work through some of these questions, and/or review some PRs.