Re: [RFC PATCH v3 15/30] io: Add a pwritev/preadv version that takes a discontiguous iovec

[Peter Xu]

On Thu, Jan 18, 2024 at 09:47:18AM -0300, Fabiano Rosas wrote:
> Peter Xu <peterx@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.

I see what you meant.  Sounds possible.

-- 
Peter Xu