[...]
>> --- a/src/util/virobject.c
>> +++ b/src/util/virobject.c
>> @@ -410,17 +410,21 @@ virObjectLock(void *anyobj)
>> * The object must be unlocked before releasing this
>> * reference.
>> */
>> -void
>> +int
>
> I'm NACK on this return value change.
>
OK - that's fine.
>>
On Fri, Jul 28, 2017 at 12:38:55PM -0400, John Ferlan wrote:
> Rather than ignore errors, let's have virObjectLockRead check for
> the correct usage and issue an error when not properly used so
> so that we don't run into situations where the resource we think
> we're locking really isn't locked
On 07/28/2017 08:26 PM, John Ferlan wrote:
>
>
> On 07/28/2017 12:56 PM, Pavel Hrdina wrote:
>> On Fri, Jul 28, 2017 at 12:38:55PM -0400, John Ferlan wrote:
>>> Rather than ignore errors, let's have virObjectLockRead check for
>>> the correct usage and issue an error when not properly used so
On 07/28/2017 12:56 PM, Pavel Hrdina wrote:
> On Fri, Jul 28, 2017 at 12:38:55PM -0400, John Ferlan wrote:
>> Rather than ignore errors, let's have virObjectLockRead check for
>> the correct usage and issue an error when not properly used so
>> so that we don't run into situations where the
On Fri, Jul 28, 2017 at 12:38:55PM -0400, John Ferlan wrote:
> Rather than ignore errors, let's have virObjectLockRead check for
> the correct usage and issue an error when not properly used so
> so that we don't run into situations where the resource we think
> we're locking really isn't locked
Rather than ignore errors, let's have virObjectLockRead check for
the correct usage and issue an error when not properly used so
so that we don't run into situations where the resource we think
we're locking really isn't locked because the void input parameter
wasn't valid.
Signed-off-by: John
