17.03.2022 00:55, Emanuele Giuseppe Esposito wrote:
Am 09/03/2022 um 14:26 schrieb Emanuele Giuseppe Esposito:
Next, I have a problem in mind, that in past lead to a lot of iotest 30
failures. Next there were different fixes and improvements, but the core
problem (as far as I understand) is still here: nothing protects us when
we are in some graph modification process (for example block-job
finalization) do yield, switch to other coroutine and enter another
graph modification process (for example, another block-job finaliztion)..
That's another point to consider. I don't really have a solution for this.
On a side note, that might not be a real problem.
If I understand correctly, your fear is that we are doing something like
parent->children[x] = new_node // partial graph operation
/* yield to another coroutine */
coroutine reads/writes parent->children[x] and/or new_node->parents[y]
/* yield back */
new_node->parents[y] = parent // end of the initial graph operation
Is that what you are pointing out here?
If so, is there a concrete example for this? Because yields and drains
(that eventually can poll) seem to be put either before or after the
whole graph modification section. In other words, even if a coroutine
enters, it will be always before or after the _whole_ graph modification
is performed.
The old example was here:
https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg05212.html - not sure
how much is it applicable now.
Another example - look at bdrv_drop_intermediate() in block.c and at TODO
comments in it.
In both cases the problem is we want to update some metadata in qcow2 (backing
file name) as part of block-graph modification. But this update does write to
qcow2 header which may yield and switch to some another block-graph
modification code.
--
Best regards,
Vladimir