On Wed, Sep 08, 2021 at 04:02:22PM +0100, Stefan Hajnoczi wrote: > > We'd have to have a whole separate API to do that, so a separate thread > > seems a > > better approach? > > Whether to support non-blocking properly in libvfio-user is a decision > for you. If libvfio-user doesn't support non-blocking, then QEMU should > run a dedicated thread instead of the partially non-blocking approach in > this patch.
Right, sure. At this point we don't have any plans to implement a separate async API due to the amount of work involved. > A non-blocking approach is nice when there are many devices hosted in a > single process or a lot of async replies (which requires extra thread > synchronization with the blocking approach). I suppose this would be more of a problem with devices where the I/O path has to be handled via the socket. regards john
