Peter Xu <pet...@redhat.com> writes:
> On Wed, Jan 17, 2024 at 03:06:15PM -0300, Fabiano Rosas wrote:
>> Oh no, you're right. Because of p->pending_job. And thinking about
>> p->pending_job, wouldn't a trylock to the same job while being more
>> explicit?
>>
>> next_channel %= migrate_multifd_channels();
>> for (i = next_channel;; i = (i + 1) % migrate_multifd_channels()) {
>> p = &multifd_send_state->params[i];
>>
>> if(qemu_mutex_trylock(&p->mutex)) {
>> if (p->quit) {
>> error_report("%s: channel %d has already quit!", __func__,
>> i);
>> qemu_mutex_unlock(&p->mutex);
>> return -1;
>> }
>> next_channel = (i + 1) % migrate_multifd_channels();
>> break;
>> } else {
>> /* channel still busy, try the next one */
>> }
>> }
>> multifd_send_state->pages = p->pages;
>> p->pages = pages;
>> qemu_mutex_unlock(&p->mutex);
>
> We probably can't for now; multifd_send_thread() will unlock the mutex
> before the iochannel write()s, while the write()s will need those fields.
Right, but we'd change that code to do the IO with the lock held. If no
one is blocking, it should be ok to hold the lock. Anyway, food for
thought.
