[...]
>>> qemuDomainObjPrivatePtr priv = obj->privateData;
>>> unsigned long long now;
>>> @@ -6395,12 +6400,18 @@ qemuDomainObjBeginJobInternal(virQEMUDriverPtr driver,
>>> }
>>>
>>> while (!nested && !qemuDomainNestedJobAllowed(priv, job)) {
>>> + if (instant)
>>> + goto cleanup;
>>> +
>>
>> If async is not supported for this (as I believe seen in the new API),
>> then is this path possible?
>
> Of course. For instance, if there's an async job running and another
> thread is trying to start a sync, non-nested job that is not allowed for
> the async job. Say, thread A is doing a snapshot which sets job mask
> (=allowed sync jobs) to: query, destroy, abort, suspend, migration-op.
> Then there's a thread B which is executing qemuDomainSetUserPassword().
> This threads tries to grab modify job. However, since grabbing modify is
> not allowed (due to job mask) thread B sits and waits until thread A
> releases the async job. At that point, thread B can safely grab modify
> job because there's no other (nor async) job running.
>
> Long story short, not only synchronous jobs serialize, also async (and
> any combination of those two) do.
>
Ah... OK.
[...]
>>> +int
>>> +qemuDomainObjBeginJobInstant(virQEMUDriverPtr driver,
>>> + virDomainObjPtr obj,
>>> + qemuDomainJob job)
>>> +{
>>> + return qemuDomainObjBeginJobInternal(driver, obj, job,
>>> + QEMU_ASYNC_JOB_NONE, true);
>> ^^^^^^^^^^^^^^^^^^^^
>> Doesn't this mean async jobs are not supported.
>
> I'm not quite sure what do you mean. You mean whether grabbing a sync
> job while there's async job already running? This is supported. The fact
> that asyncJob is QEMU_ASYNC_JOB_NONE does not mean "set sync job to @job
> and async job to QEMU_ASYNC_JOB_NONE". In fact,
> qemuDomainObjBeginJobInternal() is capable of grabbing either sync or
> async job but not both at the same time. When grabbing a sync job,
> @asynJob == QEMU_ASYNC_JOB_NONE and when grabbing an async job, @job ==
> QEMU_JOB_ASYNC.
>
> Anyway, the point of BeginJobInstant() is to be drop-in replacement for
> plain BeginJob(), so whatever the latter passes to BeginJobInternal()
> the former should mimic it. But then again, I'm not quite sure I
> understand what you mean.
>
I should have used the [1] or something to signify that this particular
comment was related to the one above where I was asking about the need
for the bool/instant check for async jobs, but I think you figured that
out even though you left a small window of self doubt ;-)
John
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
