On 5/2/22 10:02, Emanuele Giuseppe Esposito wrote:
Are you saying rdlock isn't necessary in the main loop because nothing
can take the wrlock while our code is executing in the main loop?
Yes, that's the idea.
If I am not mistaken (and I hope I am not), only the main loop currently
modifies/is allowed to modify the graph.
The only case where currently we need to take the rdlock in main loop is
when we have the case
simplified_flush_callback(bs) {
for (child in bs)
bdrv_flush(child->bs);
}
some_function() {
GLOBAL_STATE_CODE();
/* assume bdrv_get_aio_context(bs) != qemu_in_main_thread() */
bdrv_flush(bs);
co = coroutine_create(bdrv_get_aio_context(bs))
qemu_coroutine_enter(co, simplified_flush_callback)
}
This is correct, but it is very unsafe as long as bdrv_flush(bs) is
allowed to run both in coroutine context and outside. So we go circling
back to the same issue that was there in the stackless coroutine
experiment, i.e. functions that can run both in coroutine context and
outside.
This issue is fundamentally one of unclear invariants, and reminds me a
lot of the problems with recursive mutexes.
Paolo
