[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.