14.12.2018 2:28, Paolo Bonzini wrote:
> On 11/12/18 17:43, Vladimir Sementsov-Ogievskiy wrote:
>> + ThreadPool *pool = aio_get_thread_pool(bdrv_get_aio_context(bs));
>> +
>> + while (s->nb_threads >= QCOW2_MAX_THREADS) {
>> + qemu_co_queue_wait(&s->thread_task_queue, NULL);
>> + }
>> +
>> + s->nb_threads++;
>> + ret = thread_pool_submit_co(pool, func, arg);
>> + s->nb_threads--;
>> +
>> + qemu_co_queue_next(&s->thread_task_queue);
>
> What lock is protecting this manipulation? I'd rather avoid adding more
> users of the AioContext lock, especially manipulation of CoQueues.
>
> One possibility is to do the s->lock unlock/lock here, and then also
> rely on that in patch 8.
>
> Paolo
>
Hm, can you please give more details? It's refactoring commit, so, do you mean
that there is an existing bug? We are in coroutine, so, it's not safe to call
qemu_co_queue_next?
I feel, I don't understand the future without AioContext lock, and how it
influence
contexts/threads/coroutines.. So, from this context, s->thread_task_queue may be
accessed from other thread, when we are here, and calling qemu_co_queue_next
from
our aio context? But from where? /Sorry for may be stupid questions/
--
Best regards,
Vladimir
