On 06/07/2017 12:55 AM, Michal Privoznik wrote:
On 06/06/2017 07:24 PM, Jim Fehlig wrote:
> On 06/05/2017 06:53 AM, Michal Privoznik wrote:
>> There's a problem with current streams after I switched them from
>> iohelper to thread implementation. Previously, iohelper made sure
>> not to exceed specified @length resulting in the pipe EOF
>> appearing at the exact right moment (the pipe was used to tunnel
>> the data from the iohelper to the daemon). Anyway, when switching
>> to thread I had to write the I/O code from scratch. Whilst doing
>> that I took an inspiration from the iohelper code, but since the
>> usage of pipe switched to slightly different meaning, there was
>> no 1:1 relationship between the codes.
>>
>> Moreover, after introducing VIR_FDSTREAM_MSG_TYPE_HOLE, the
>> condition that should made sure we won't exceed @length was
>> completely wrong.
>>
>> The fix is to:
>>
>> a) account for holes for @length
>> b) cap not just data sections but holes too (if @length would be
>> exceeded)
>>
>> For this purpose, the condition needs to be brought closer to the
>> code that handles holes and data sections.
>
> For the record, this fixes the libvirt-tck failures I mentioned. Thanks!
I think this made it harder to hit the hang.
Indeed. Looping through the tests 25 times produced no failures. Before this
patch, roughly 2/3 of those would fail.
Thanks for the pointer. I reviewed it.
Regards,
Jim