On 05/21/2011 01:21 AM, Paolo Bonzini wrote:
> On 05/21/2011 12:11 AM, Eric Blake wrote:
>> I think we're safe. It shouldn't matter if thread 2 reads thread 3's
>> answer (because they are both read-only queries, and should be getting
>> the same answer; or even if the answers differ, reading the
On 05/21/2011 12:11 AM, Eric Blake wrote:
I think we're safe. It shouldn't matter if thread 2 reads thread 3's
answer (because they are both read-only queries, and should be getting
the same answer; or even if the answers differ, reading the newer answer
is not horrible because it is still an ac
On 05/20/2011 03:11 PM, Paolo Bonzini wrote:
> On 05/16/2011 07:30 PM, Eric Blake wrote:
>> +while (priv->jobSignals& QEMU_JOB_SIGNAL_BLKSTAT)
>> +ignore_value(virCondWait(&priv->signalCond,&vm->lock));
>> +
>> +priv->jobSignalsData.statDevName = disk->info.alias;
>> +
On 05/16/2011 07:30 PM, Eric Blake wrote:
> +while (priv->jobSignals& QEMU_JOB_SIGNAL_BLKSTAT)
> +ignore_value(virCondWait(&priv->signalCond,&vm->lock));
> +
> +priv->jobSignalsData.statDevName = disk->info.alias;
> +priv->jobSignalsData.blockStat = stats;
> +
From: Federico Simoncelli
Originally most of libvirt domain-specific calls were blocking
during a migration.
A new mechanism to allow specific calls (blkstat/blkinfo) to be
executed in such condition has been implemented.
In the long term it'd be desirable to get a more general
solution to mark f
