Re: [Qemu-devel] [PATCH v2 4/8] qcow2-threads: split out generic path

[Vladimir Sementsov-Ogievskiy]

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