On Wed, Jul 18, 2012 at 06:42:24AM -0400, Paolo Bonzini wrote: > > Synchronous APIs are great for writing dedicated tools like dd, cp, > > convert, etc. > > > > Asynchronous APIs are essential for integrating image file I/O into > > event-driven programs like libvirt. Here, the ability to do other > > things while image file I/O is in progress is a requirement. It may > > also be necessary to cancel or timeout if an operation is not making > > progress or the user decides to stop it. > > > > I think we need to provide both sync and async. Libraries like > > libssh2 and libcurl already do this so their APIs can be used as a > > starting point for async I/O. > > If we want to provide an asynchronous API, the easiest thing would > be to provide a GSource and that's it. That would even make sense for > QEMU itself, in fact. > > What I'm worried about, is how to support _both_ synchronous and > asynchronous access. I'd like the library to be clean of things like > qemu_aio_wait() and qemu_aio_flush(), at least in the beginning. > That's why I think async can come later, once we actually get > applications needing it. Right now, libvirt's requirements are > simple (e.g. probing the backing file chain) and would be synchronous > anyway.
Yes, qemu_aio_wait() and qemu_aio_flush() are ugly. Starting with sync makes sense, it's a convenient API to have even if we add async later. Stefan
