Re: [Xen-devel] [PATCH v2 16/27] tools/libxl: Infrastructure for reading a libxl migration v2 stream

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 10/07/15 13:46, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH v2 16/27] tools/libxl: Infrastructure for 
> reading a libxl migration v2 stream"):
>> On 10/07/15 12:25, Ian Campbell wrote:
>>> Do you mean they would do so legitimately in that case, or in error?
>> It is wrong in all cases to mutually recurse like this.  The data
>> controlling the degree of mutual recursion is read from a pipe.
>>
>> The issue with the TOOLSTACK record is that it a synchronous library
>> call, not an aync one.  This is not a problem pe say, but it means that
>> process_record() must queue something further to do.
>>
>> In a checkpoint it is possible (although very unlikely) to have $N
>> thousand TOOLSTACK records back to back.
>>
>> The guards are in place to prevent introducing a codepath which does end
>> up in mutual recursion.  Such a calltree would function for any
>> reasonable input, but would fall off the stack given a certain sequence
>> of records.
> I just wanted to say that I have read this and it helps my
> understanding but I still worry about the correctness of
> stream_continue and process_record if the queue has more than one
> record.

This might also make more sense with the context from patch 25, which is
where the Remus/COLO buffering is introduced.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel