> Whether to provide sync and/or async access is a key question. Indeed.
> 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. Paolo
