On Fri, Jan 13, 2017 at 02:17:20PM +0100, Paolo Bonzini wrote: > /** > + * qio_channel_set_aio_context: > + * @ioc: the channel object > + * @ctx: the #AioContext to set the handlers on > + * > + * Request that qio_channel_yield() sets I/O handlers on > + * the given #AioContext. If @ctx is %NULL, qio_channel_yield() > + * uses QEMU's main thread event loop. > + */ > +void qio_channel_set_aio_context(QIOChannel *ioc, > + AioContext *ctx); > + > +/** > + * qio_channel_detach_aio_context: > + * @ioc: the channel object > + * > + * Disable any I/O handlers set by qio_channel_yield(). With the > + * help of aio_co_schedule(), this allows moving a coroutine that was > + * paused by qio_channel_yield() to another context. > + */ > +void qio_channel_detach_aio_context(QIOChannel *ioc);
The block layer's bdrv_set_aio_context() has different semantics. It invokes .detach()/.attach() callbacks and does AioContext locking so the function can be called safely even while the block driver is waiting for events. It's unfortunate to that the block and io channel APIs act differently despite having similar names. Was there a reason to choose different semantics? > + > +/** > * qio_channel_yield: > * @ioc: the channel object > * @condition: the I/O condition to wait for > * > - * Yields execution from the current coroutine until > - * the condition indicated by @condition becomes > - * available. > + * Yields execution from the current coroutine until the condition > + * indicated by @condition becomes available. @condition must > + * be either %G_IO_IN or %G_IO_OUT; it cannot contain both. In > + * addition, no two coroutine can be waiting on the same condition s/coroutine/coroutines/
signature.asc
Description: PGP signature
