Hi, >> How would the parallel execution facility be opaque to the implementer? >> screendump returns, screendump_async needs to pass a closure. You can >> automatically generate any amount of code, but you can only have a >> single function implementation with longjmp/coroutine, or having a >> saparate thread per command but that would mean taking locks for >> anything not trivial, which avoids the no-change-to-implementation. Is >> this what you have in mind? > > It would not be opaque to the implementer. But it would avoid > introducing new commands and events, instead we have a unified mechanism > to signal completion.
Ok. We have a async mechanism today: .mhandler.cmd_async = ... I know it has its problems like no cancelation and is deprecated and all. But still: how about using it as interim until QAPI-based async monitor support is ready? We could unbreak qxl screendumps without having to introduce a new (but temporary!) screendump_async command + completion event. cheers, Gerd
