On Tue, May 17, 2016 at 04:57:28PM +0200, Paolo Bonzini wrote:
> That said, there is at least another case where it will be used. In the
> dataplane branch, where AIO callbacks take the AioContext mutex
> themselves, we have:
>
> static void bdrv_co_io_em_complete(void *opaque, int ret)
> {
>
On 19/04/2016 16:31, Stefan Hajnoczi wrote:
> On Fri, Apr 15, 2016 at 01:31:59PM +0200, Paolo Bonzini wrote:
>> @@ -255,6 +257,8 @@ aio_ctx_finalize(GSource *source)
>> }
>> #endif
>>
>> +qemu_bh_delete(ctx->schedule_bh);
>
> Please include an assertion that the scheduled corouti
On 29/04/2016 07:11, Fam Zheng wrote:
> > +int main(int argc, char **argv)
> > +{
> > +init_clocks();
> > +
> > +g_test_init(&argc, &argv, NULL);
> > +g_test_add_func("/aio/multi/lifecycle", test_lifecycle);
> > +if (g_test_quick()) {
> > +g_test_add_func("/aio/multi/sched
On Fri, 04/15 13:31, Paolo Bonzini wrote:
> This provides the infrastructure to start a coroutine on a remote
> AioContext. It will be used by CoMutex and CoQueue, so that
> coroutines don't jump from one context to another when they
> go to sleep on a mutex or waitqueue.
>
> aio_co_schedule is b
On Fri, Apr 15, 2016 at 01:31:59PM +0200, Paolo Bonzini wrote:
> @@ -255,6 +257,8 @@ aio_ctx_finalize(GSource *source)
> }
> #endif
>
> +qemu_bh_delete(ctx->schedule_bh);
Please include an assertion that the scheduled coroutines list is empty.
> +
> qemu_lockcnt_lock(&ctx->li
This provides the infrastructure to start a coroutine on a remote
AioContext. It will be used by CoMutex and CoQueue, so that
coroutines don't jump from one context to another when they
go to sleep on a mutex or waitqueue.
aio_co_schedule is based on a lock-free multiple-producer,
single-consumer
