On 06/25/2017 04:51 AM, Michal Privoznik wrote:
> On 06/25/2017 12:34 AM, John Ferlan wrote:
>>
>>
>> On 06/24/2017 01:13 PM, Michal Privoznik wrote:
>>> On 06/24/2017 01:26 PM, John Ferlan wrote:
On 06/23/2017 05:39 AM, Michal Privoznik wrote:
> On 06/23/2017 12:10 AM, John
On 06/25/2017 12:34 AM, John Ferlan wrote:
>
>
> On 06/24/2017 01:13 PM, Michal Privoznik wrote:
>> On 06/24/2017 01:26 PM, John Ferlan wrote:
>>>
>>>
>>> On 06/23/2017 05:39 AM, Michal Privoznik wrote:
On 06/23/2017 12:10 AM, John Ferlan wrote:
> If a remote call fails during event
On 06/24/2017 01:13 PM, Michal Privoznik wrote:
> On 06/24/2017 01:26 PM, John Ferlan wrote:
>>
>>
>> On 06/23/2017 05:39 AM, Michal Privoznik wrote:
>>> On 06/23/2017 12:10 AM, John Ferlan wrote:
If a remote call fails during event registration (more than likely from
a network failure
On 06/24/2017 01:26 PM, John Ferlan wrote:
>
>
> On 06/23/2017 05:39 AM, Michal Privoznik wrote:
>> On 06/23/2017 12:10 AM, John Ferlan wrote:
>>> If a remote call fails during event registration (more than likely from
>>> a network failure or remote libvirtd restart timed just right), then when
On 06/23/2017 05:39 AM, Michal Privoznik wrote:
> On 06/23/2017 12:10 AM, John Ferlan wrote:
>> If a remote call fails during event registration (more than likely from
>> a network failure or remote libvirtd restart timed just right), then when
>> calling the virObjectEventStateDeregisterID we
On 06/23/2017 12:10 AM, John Ferlan wrote:
> If a remote call fails during event registration (more than likely from
> a network failure or remote libvirtd restart timed just right), then when
> calling the virObjectEventStateDeregisterID we don't want to call the
> registered @freecb function
If a remote call fails during event registration (more than likely from
a network failure or remote libvirtd restart timed just right), then when
calling the virObjectEventStateDeregisterID we don't want to call the
registered @freecb function because that breaks our contract that we
would only